202 Accepted
2xx success
The request was accepted for processing, but the work isn't finished yet.
202 is an honest 'I'll get to it'. The server validated the request and queued it — a video transcode, a report, a bulk import — but makes no promise that the work will succeed. A good 202 tells the client where to check progress, usually with a Location header pointing at a status endpoint or a job id in the body.
| Class | 2xx Success |
|---|---|
| Retry? | Not applicable |
| Cacheable by default | No — only with explicit Cache-Control |
| Response body | Allowed |
| Defined in | RFC 9110 §15.3.3 — 202 Accepted |
HTTP/1.1 202 Accepted Location: /jobs/8f3a Content-Type: application/json
When you'll see it
- Asynchronous jobs: exports, batch imports, media processing.
- Webhook receivers that acknowledge quickly and process in the background.
How to use it well
- Return a status URL (in
Locationor the body) that the client can poll. - Have the status endpoint report progress while running, then point at the result — 303 See Other works well — when done.
- Don't use 202 for requests that already failed validation; that's a 4xx.
Send a 202 from your server
res.set("Location", "/jobs/8f3a");
res.status(202).json(result);return Response.json(result, { status: 202, headers: { "Location": "/jobs/8f3a" } });return result, 202, {"Location": "/jobs/8f3a"}w.Header().Set("Location", "/jobs/8f3a")
w.WriteHeader(http.StatusAccepted)add_header Location "/jobs/8f3a" always; return 202;
Check what a URL returns
Print just the status line from the command line, or check a whole list of URLs at once, with their response headers, in the HTTP Status Checker.
curl -sI https://example.com/your-path | head -n 1
Frequently asked questions
How should clients wait for a 202 job?
Poll the status URL with backoff, or have the server call a webhook when the job completes. A Retry-After header on the status response can suggest the polling interval.
Why do webhook providers want a fast 2xx?
Most retry if you don't answer within a few seconds. Acknowledging with 202 and processing from a queue avoids duplicate deliveries caused by timeouts.