HTTP 202 Accepted
HTTP 202 Accepted means the server received and accepted the request for processing, but that processing has not been completed. The request may be processed later, asynchronously, or in a batch. The final result is not available in this response.
Quick reference
| Code | 202 |
|---|---|
| Name | Accepted |
| Category | 2xx Success |
| Specification | RFC 9110 §15.3.3 |
| IANA status | Assigned |
| Cacheable | No — not cached by default |
| Client action | Poll the status endpoint or use a webhook to get the final result. |
| In-depth guide | HTTP 202 full guide → |
What HTTP 202 means
RFC 9110 defines 202 as indicating that the request has been accepted for processing, but the processing has not been completed. It intentionally does not commit to whether the request will ultimately be fulfilled — only that it was accepted and queued. The server may still reject the request during processing.
202 is the correct response for any long-running or asynchronous operation: video encoding jobs, bulk data imports, email dispatch, report generation, database migrations, or any task that would take longer than a reasonable HTTP request timeout to complete synchronously.
The distinction from 200 OK: 200 means the result is in this response. 202 means the result will be available later, somewhere else. The response body for a 202 should tell the client where and how to get the result.
Providing a status endpoint
A 202 response without guidance on how to get the result is an incomplete implementation. The response should include either a status polling URL or instructions for webhook delivery. The most common pattern is a job status endpoint:
HTTP/1.1 202 Accepted
Content-Type: application/json
Location: /jobs/7f3a9c12
{
"job_id": "7f3a9c12",
"status": "queued",
"status_url": "https://api.example.com/jobs/7f3a9c12",
"estimated_completion": "2026-04-25T10:35:00Z"
}
The client polls /jobs/7f3a9c12 until the status changes to completed or failed. The completed response returns the result or a link to it. This polling pattern is the standard implementation for 202-based async APIs.
Common use cases
Long-running background jobs
Anything that takes more than a few seconds and should not hold an HTTP connection open: video transcoding, PDF generation, machine learning inference jobs, bulk email sending, data export generation.
Queued message processing
When a request is pushed to a queue (SQS, RabbitMQ, Kafka) for worker processing, the HTTP server can acknowledge the message receipt with 202 without waiting for the worker to process it.
Rate-limited operations
Operations that are throttled or batched — social media posts queued for later publishing, analytics event collection, batch data ingestion — can return 202 to indicate the item was accepted into the queue.
202 vs 200 vs 204
FAQ
What does HTTP 202 Accepted mean?
HTTP 202 means the server accepted the request but has not finished processing it. The result will be available later via a status endpoint or webhook. The response body should tell the client how to check status.
How is 202 different from 200?
200 means the operation is complete and the result is in the response. 202 means the operation was accepted and is being processed — the result is not in this response and is not yet available.
What should a 202 response body contain?
A job ID, a status polling URL, and ideally an estimated completion time. Without this information, the client has no way to get the result of the accepted request.
Can processing fail after a 202?
Yes. RFC 9110 explicitly notes that the server makes no commitment about the final outcome. A 202 only guarantees acceptance, not success. The client must check the job status endpoint to learn whether processing succeeded or failed.
Related resources
On this site: HTTP 202 Accepted — full guide · HTTP 200 OK · HTTP 201 Created · HTTP 204 No Content · All 2xx success codes
Standards: RFC 9110 §15.3.3 · IANA HTTP Status Code Registry · MDN Web Docs: 202