202 Accepted

This is an educational reference page about HTTP 202 Accepted. The page itself is served as 200 OK so it can be indexed as HTTP documentation.

The server accepted the request for processing but has not finished it. The work may still fail or be rejected later.

Specification

Registered in the IANA HTTP Status Code Registry as Accepted. Defined in RFC 9110, Section 15.3.3.

What it means

HTTP 202 Accepted means the server accepted the request but has not finished processing it. RFC 9110 calls 202 intentionally noncommittal: the request might still be rejected when the work runs, and HTTP has no way to send a second status code when the background job finishes.

When to use it

Return 202 when a request starts a background job, such as a video transcode, a report export, or a bulk import.
Return 202 when the work runs in a batch process that the client should not wait for.
Return 201 instead when the resource exists by the time you respond.

Headers involved

Location can point to a status resource the client can poll. RFC 9110 does not define Location for 202, so document the meaning in your API docs.
Retry-After can suggest when to poll next. RFC 9110 defines Retry-After for 503 and 3xx only, so document this use too.
Content-Type describes the body, which should say what was accepted and how to check progress.

Examples

Start an export job

POST /api/exports HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "format": "csv",
  "range": "2026-Q3"
}

HTTP/1.1 202 Accepted
Location: /api/exports/jobs/7781
Retry-After: 10
Content-Type: application/json

{
  "jobId": "7781",
  "status": "queued",
  "statusURL": "/api/exports/jobs/7781"
}

Poll the job status

GET /api/exports/jobs/7781 HTTP/1.1
Host: api.example.com

HTTP/1.1 200 OK
Content-Type: application/json

{
  "jobId": "7781",
  "status": "done",
  "download": "/api/exports/7781.csv"
}

Common mistakes

Returning 202 without any way to check the result. Include a job ID, a status URL, or a callback contract.
Using 202 for work that already finished. Clients then poll for no reason.
Treating 202 as a promise that the work will succeed. Clients still need to handle a failed job.

Developer notes

With 202, the HTTP exchange ends before the work does, so the job's outcome has to come from somewhere else: a status endpoint the client polls, a webhook, or an email. The status endpoint itself returns normal codes, usually 200 with a status field that tells the client whether the job is queued, running, done, or failed.

Questions

What does HTTP 202 Accepted mean?

HTTP 202 means the server accepted the request for processing but has not finished it. The final outcome is reported another way, such as a status URL.

Should an async API return 202 or 201?

Return 202 when the resource is created later by a background job. Return 201 when the resource exists when you send the response.

Header and content rules

What RFC 9110 says about a 202 response, quoted from the RFC.

No keyword (sender; content): Describe the current status of the request and point to, or embed, a status monitor. RFC 9110 says "ought to", which is not a BCP 14 keyword. Table row
The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled. RFC 9110 §15.3.3

The same rule is in the response obligations table and its JSON.