202 Accepted
The request was accepted for processing, but has not been completed yet.
What 202 means
202 is the asynchronous answer: the server has taken responsibility for the request but the work is not finished, and may not even have started. It is the right response when a request triggers a job, a batch, a workflow or anything else that outlives the HTTP exchange.
Because the outcome is unknown at response time, 202 is a commitment to accept the work rather than a report of success. That means the client needs some way to find out what happened - and providing it is the part that is usually missing.
The useful pattern is to return a Location header pointing at a status resource the client can poll, or to accept a callback URL. A 202 with no way to discover the outcome leaves the client unable to distinguish 'still running' from 'failed silently'.
Headers this status expects
- Location - a status or job resource the client can poll for progress and outcome.
- Retry-After - how long to wait before polling, so clients do not hammer the status endpoint.
Should a client retry?
The work is already queued. Retrying submits it again - poll the status resource instead.
FAQ
- When should I use 202 instead of 200?
- When the request starts work that will finish after the response is sent - a background job, a batch import, a long-running workflow. 200 claims the work is done; 202 honestly says it has only been accepted.
- How does the client find out whether the work succeeded?
- Give it a way: a Location header pointing at a job status resource to poll, or a webhook callback. A 202 with no follow-up mechanism is not actionable.
Often confused with
- 200 OK The request succeeded and the response carries the result.
- 201 Created The request succeeded and created a new resource.