202 Accepted — HTTP Status Code

202 Accepted means "got it, working on it." The server has taken the request, probably put it in a queue, and closed the HTTP exchange without waiting for the result. Nothing has been confirmed except that the request arrived and passed the first checks.

What 202 means

RFC 9110 (Section 15.3.3) defines 202 as a request accepted for processing where processing has not been completed. The RFC is careful about what that does not promise:

• The request might never be carried out, because it could be refused once processing actually begins.
• There is no mechanism in HTTP for the server to send another status code later about the same request.
• The response is described as intentionally noncommittal. Its purpose is to let a server accept work for another process, perhaps a batch job, without making the client hold a connection open until it finishes.

The RFC suggests the response body should describe the request's current status and point to, or embed, a status monitor that tells the user when the work might be done.

When you see it

202 appears wherever work takes longer than a reasonable HTTP timeout:

• Exports and reports. "Your CSV is being prepared" endpoints accept the request and email a link later.
• Media processing. Video transcoding, image resizing at scale, document conversion.
• Bulk operations. Importing thousands of rows, sending a large email campaign, reindexing search.
• Webhook receivers. A receiver may store the event, return 202 right away, and handle it in a background worker so the sender is not kept waiting.
• Cloud and infrastructure APIs. Creating a server or a database often returns 202 with an operation id to poll.

A common response shape:

HTTP/1.1 202 Accepted
Location: /v1/jobs/7f3a
Retry-After: 10
Content-Type: application/json

{"job": "7f3a", "status": "queued"}

The client then polls /v1/jobs/7f3a until it reports done or failed. Using Location and Retry-After here is a common API convention, not something RFC 9110 requires for 202.

Designing around 202

If you build an API that returns 202:

1. Give the job an id and a status URL. Without it, the client cannot learn whether the work happened.
2. Report failure clearly on the status URL, with a reason. A job that silently disappears is the worst outcome of a 202 design.
3. Make the status endpoint cheap, since clients will poll it. Suggest a polling interval.
4. Offer a webhook for completion if clients would otherwise poll for minutes.
5. Keep the request idempotent where you can, so a client that retries after a network error does not start the job twice.

Do not return 202 when you could finish the work quickly. If the record is created before the response is sent, 201 Created or 200 OK is more useful.

How to check it

Like 201, a 202 usually comes from a POST, so curl -I (a HEAD request) will not trigger it. Send the real request and show headers:

curl -s -D - -o /dev/null -X POST https://api.example.com/v1/exports \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" -d '{"format":"csv"}'

Then follow the Location header with a GET to see the job status:

curl -s https://api.example.com/v1/jobs/7f3a -H "Authorization: Bearer $TOKEN"

What it means for uptime monitoring

A final status of 202 counts as up, since PingRobot's checker treats anything from 200 to 399 as up. A GET rarely produces 202, though, because there is normally nothing to queue on a read.

The bigger lesson is what 202 hides: the queue and the workers behind it. The API can accept requests happily while the background workers are stuck, crashed or out of disk, and every HTTP check stays green. Two ways to see that failure:

• Heartbeat from the worker. Have the worker, or a scheduled job that runs after each batch, ping a heartbeat URL. If the worker stops, the heartbeat goes late and you get alerted.
• Expose queue health over HTTP. A status route that returns 200 only when the oldest queued job is younger than a threshold, and 503 otherwise, turns a silent backlog into something an HTTP monitor can catch. A keyword monitor on a word such as healthy in that response works too.

Related codes

• 200 OK — the work finished within the request
• 201 Created — a resource exists now, not later
• 204 No Content — done, with nothing to return
• 429 Too Many Requests — the server will not accept more work right now
• 503 Service Unavailable — the service cannot take requests at all

Start monitoring free — 10 monitors, no credit card.