202 Accepted
The request was accepted for processing, but the work has not finished and may still fail.
Status
HTTP/1.1 202 Accepted
Details
- Category: 2xx
- Status: Standard. Registered with IANA and defined by a current standards-track RFC.
- Specification: RFC 9110 §15.3.3
- Cacheable: Only with explicit cache headers
- Response body: Allowed
- Retry: Do not retry
202 decouples acceptance from completion. The server has queued the work and is deliberately declining to hold the connection open while it runs. Nothing is promised about the outcome: the job may later succeed, fail, or be rejected outright.
Because it makes no promise, a useful 202 always tells the client how to find out what happened. That means a status URL in the body or in Location, and ideally an estimate of when to check back. A 202 with an empty body leaves the caller with no way to reconcile state.
Headers
- Location: Often points at a status resource the client can poll for progress.
- Retry-After: Optional hint for how long to wait before polling the status resource.
Common causes
- A request kicked off asynchronous work such as provisioning, batch import, video transcoding, or report generation.
- A write was enqueued for a downstream system that is processed out of band.
How to fix it
As the client
- Poll the status resource with backoff instead of assuming the work succeeded.
- Persist the job identifier. Losing it means losing the ability to reconcile what happened.
As the server
- Return a status URL, a job ID, and a terminal state model the client can poll.
- Keep completed job records around long enough for slow clients to read the result.
Examples
POST /api/reports HTTP/1.1
Host: api.example.com
Content-Type: application/json
{"range":"2026-08","format":"csv"}
HTTP/1.1 202 Accepted
Location: /api/reports/jobs/9f21
Retry-After: 10
Content-Type: application/json; charset=utf-8
{"job_id":"9f21","state":"queued"}