Runs in your browser. Your files and text never leave your device - nothing is uploaded.
2xx Success
What it means
The request has been accepted for processing, but processing is not yet complete.
| Property | Detail |
|---|---|
| Status class | 2xx Success |
| Defined in | RFC 9110, Section 15.3.3 |
| Cacheable by default | Only with explicit caching headers: a cache stores it when the response carries Cache-Control (max-age, s-maxage or public) or Expires. |
| Who needs to act | The client, which has to check the outcome of the job later. |
What does HTTP 202 Accepted mean?
HTTP 202 Accepted means the server has accepted the request for processing but has not finished it, and may still reject it when the work actually runs. APIs use it for slow jobs such as exports, video encoding or bulk imports, returning immediately with a way for the client to check progress later.
How 202 Accepted works
RFC 9110 calls 202 intentionally noncommittal. It lets a server hand work to a queue or a batch process without keeping the connection open until the work is done, but HTTP has no way to deliver the final outcome later: there is no second status code for the same request. The body is therefore expected to describe the current state and point to, or embed, a status monitor. Common designs are a status URL to poll, a webhook the server calls when the job ends, or both. DELETE can also return 202, when removal has been scheduled but not yet carried out.
Example 202 request and response
POST /api/exports HTTP/1.1
Host: api.example.com
Content-Type: application/json
HTTP/1.1 202 Accepted
Content-Type: application/json
{"status": "queued", "statusUrl": "/api/exports/jobs/5521"}The body points to a status monitor. Polling that URL reports progress and, eventually, where to download the finished export.
When servers send 202 Accepted
- Report or data exports generated in the background.
- Media uploads that are transcoded after the request returns.
- Bulk imports, emails or notifications pushed onto a queue.
- A DELETE that schedules removal rather than performing it immediately.
How to handle 202 Accepted
If you call the API
- Poll the status URL at a sensible interval and back off, rather than resubmitting the original request.
- Handle the job failing later: a 202 is not a promise of success.
- Use webhooks where the API offers them, to avoid polling altogether.
If you build the API
- Return a job ID and status URL in the body.
- Make the status endpoint report clear states such as queued, running, succeeded and failed, plus where the result lives.
- Keep finished job records long enough for slow clients to collect the result, and document how long that is.
- Return 201 instead if the resource is fully created before you respond.
Related status codes
- 201 Created: The resource already exists when the response is sent.
- 200 OK: The work finished during the request and the body holds the result.
- 102 Processing: An older WebDAV approach that kept the connection open with interim responses instead of returning early.
Frequently asked questions
The request has been accepted for processing, but processing is not yet complete.
Used for asynchronous operations where the server queues the work rather than completing it immediately.
No fix needed - poll a status endpoint or wait for a callback/webhook to confirm completion.
Only that it was accepted. RFC 9110 says the request might or might not eventually be acted upon, because it can still be refused when processing happens. Check the job status before treating the work as done.
Sources
Other 2xx Success codes
Reviewed by Raja Jahangir · Last reviewed: October 7, 2026