202 Accepted 2xx
The request has been accepted for processing, but the processing has not been completed.
What does 202 mean?
A 202 Accepted response means the server has received and acknowledged the request, and the request is valid and will be processed — but processing hasn't finished yet, and might not finish for a while. It's the standard response for asynchronous operations: the client doesn't wait around for the work to complete; instead, it gets immediate confirmation that the work has been queued, along with (ideally) a way to check on progress later.
This is the modern, widely-adopted alternative to the pattern 102 Processing originally tried to address — rather than holding a connection open with periodic "still working" signals, 202 closes the loop immediately and shifts "checking on progress" to a separate mechanism (polling a status endpoint, a webhook callback, etc.).
How a 202 behaves
- It typically includes a way to check status — a
Locationheader pointing to a status-check endpoint, a job ID in the response body, or documentation describing how the client will be notified of completion (webhook, etc.) - The eventual outcome is not guaranteed at the time of the 202 response — the operation might ultimately succeed or fail; 202 only confirms it was accepted for processing, not that it will definitely complete successfully
- It's not cacheable in a meaningful sense — represents the state at submission time, which will change as processing completes
- It decouples request submission from result availability — this is its core architectural purpose, enabling patterns where processing might take seconds, minutes, or longer without holding a client connection open for the duration
Common scenarios
If you're building the API or website:
- An operation that takes significant time — generating a large report, processing an uploaded file, sending bulk emails/notifications, running a complex computation — is queued for background processing, and 202 confirms acceptance immediately
- You're implementing a job queue system where API requests create jobs, and 202 (with a job ID/status URL) is the standard response pattern for job-creation endpoints
If you're calling an API:
- After receiving 202, use the provided status-check mechanism (polling a URL, or waiting for a webhook) to determine when the operation completes and what the final result is
- Don't treat 202 as confirmation that the underlying operation succeeded — only that it was accepted for processing; the final outcome requires checking status separately
If you're a website visitor:
- Actions that show "we'll email you when this is ready" or "your request is being processed" messages often correspond to a 202 response behind the scenes — the action was accepted, but the actual work happens afterward
200 vs 201 vs 202
| Code | Meaning | Timing |
|---|---|---|
| 200 OK | Request succeeded, here's the result | Synchronous — result is available immediately |
| 201 Created | Request succeeded, a new resource now exists | Synchronous — the resource exists by the time you get the response |
| 202 Accepted | Request accepted, processing will happen separately | Asynchronous — the actual result/outcome comes later |
Real-world examples
Bulk operations (sending large batches of emails, processing large file uploads, generating reports/exports) commonly return 202 with a job identifier, and provide a separate status endpoint clients poll (e.g., GET /jobs/{id}) to check whether the operation has completed and retrieve the result once it has. Webhook-based integrations often pair with 202 — an API accepts a request immediately with 202, processes it asynchronously, and then calls a webhook URL the client registered, to notify them of completion rather than requiring polling.
SEO implications
None — 202 is exclusively relevant to asynchronous API operations and has no bearing on page-level content delivery.
FAQ
What's the difference between 200 and 202?
200 means the request was fully processed and here's the result, right now. 202 means the request was accepted and will be processed, but not necessarily by the time you receive this response — you'll need to check back separately for the actual outcome.
How do I know when a 202'd operation actually finishes?
The API should provide a mechanism for this — commonly a Location header or job ID pointing to a status-check endpoint you can poll, or a webhook that fires when processing completes. Check the specific API's documentation for which pattern it uses.
Can a 202'd operation fail after being accepted?
Yes — 202 only confirms the request was valid and accepted for processing; it doesn't guarantee the eventual outcome. The status-check mechanism should report whether the operation ultimately succeeded or failed, and why, once processing completes.
Why use 202 instead of just making the client wait for 200?
For operations that take a long time (seconds to hours), holding a connection open isn't practical — connections can time out, resources get tied up, and the user experience of "loading..." for an extended period is poor. 202 lets the client move on immediately and check back later, which scales much better for long-running work.
Is 202 only for "big" operations like reports and bulk emails?
Those are common examples, but the underlying pattern — "accept now, process later, check status separately" — applies to any operation where synchronous processing isn't practical or desirable, including operations that are individually fast but are queued for rate-limiting, ordering, or resource-management reasons.
Fun fact
202 represents one of HTTP's cleanest examples of "honesty by design" — rather than making the client wait (potentially timing out) or returning a misleading "success" before work is actually done, 202 explicitly carves out a third option: "I heard you, I'm on it, but I'm not done yet" — a status code essentially built around managing expectations, which turns out to be foundational to how most real-world distributed systems and job queues communicate.