2xx Success · RFC 9110 §15.3.3

202 Accepted

The request was accepted for processing, but processing has not finished.

What 202 means

Used for asynchronous work: the server queued the job and will finish later. The response typically links to a status endpoint the client can poll.

It makes no promise that the work will succeed. Failures after a 202 are reported through the status endpoint, a callback or an email, never through the original response.

Common causes

  • The request started a background job, export, batch import or long-running provisioning step.

How to fix it

  • Provide a status URL (Location or a body field) and document how long the client should wait between polls.

What it looks like

A typical response:

HTTP/1.1 202 Accepted
Location: /api/exports/42/status
Retry-After: 5

The same event in an nginx access log (the status is the number after the request line):

203.0.113.7 - - [10/Sep/2026:10:12:01 +0000] "POST /api/orders HTTP/1.1" 202 153 "-" "Mozilla/5.0"

Check it with curl

-i prints the status line and headers, and -w '%{http_code}' prints only the number, which is handy in scripts and health checks. Replace the URL with yours:

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://example.com/api/orders

Compare what curl sees with what the browser sees. A different status from the same URL usually means a cache, a CDN edge or a cookie is in the way.

Investigating a run of 202s? Paste the log excerpt into Log Share to get line numbers, highlighting and an expiring link for whoever is on call with you.

  • 200OK: The request succeeded and the response carries the result.
  • 201Created: The request created a new resource, identified by the Location header.
  • 303See Other: The result is at another URL; fetch it with GET.

FAQ

When should I use 202 instead of 200?

When the response is sent before the work completes. If the client would otherwise wait longer than a few seconds, queue the job and return 202.