202 Accepted

The request has been accepted for processing, but that processing has not completed and may not have started yet.

Defined in RFC 9110 §15.3.3

What 202 means

HTTP 202 Accepted tells the client that the request was valid and has been queued or handed off for processing, without promising that the work is done, or even that it will succeed, by the time the response is sent. This is the standard way to acknowledge asynchronous operations: a request to generate a report, send a bulk email campaign, or process an uploaded video can return immediately with 202 while the actual work happens on a background worker, queue, or separate service. The client is expected to check back later rather than treat the response as a finished result.

A well-designed 202 response usually includes a way to track progress, either a Location header pointing at a status resource the client can poll, or a body containing a job or task identifier the client can look up through a separate endpoint. Without that, 202 leaves the caller with no way to know when, or whether, the operation finished, which makes the API awkward to use correctly. Some designs pair 202 with a webhook callback instead of polling, notifying the client when the job transitions to a terminal state.

Because the outcome is not yet known, 202 must never be treated as equivalent to success; the eventual result could be a completed resource, a partial failure, or a full failure discovered later during processing. This makes 202 fundamentally different from 200 or 201, which both describe a definite, already-known outcome. API consumers that log 202 responses as successful completions can end up masking real failures that only surface once the asynchronous job actually runs and errors out downstream.

Common causes

A request triggers work that is handed off to a background job, queue, or worker instead of being processed synchronously.
The operation, such as sending a batch of emails or generating a large export, is expected to take longer than a reasonable request timeout.
The server accepts the request for later processing without yet validating every detail that could cause the eventual job to fail.
A webhook or callback-based integration acknowledges receipt of an event before actually acting on it.
A rate-limited or load-shedding system queues work during traffic spikes instead of processing it immediately.

How to fix a 202

If you are the client (browser user or API caller)

Poll the status URL returned in the Location header, or the job ID in the body, instead of treating 202 itself as the final outcome.
Implement exponential backoff for status polling rather than hammering the status endpoint at a fixed short interval.
Subscribe to a webhook callback where the API offers one, instead of polling, to learn about completion or failure sooner.
Surface accepted-but-pending state distinctly in your UI or logs so it is not confused with a completed operation.

If you run the server

Always return a way to check progress, a Location header to a status resource or a job ID in the body, when responding 202.
Validate as much of the request as practical before returning 202, so obviously invalid requests fail fast with a 4xx instead of failing later inside the queue.
Make the status endpoint clearly report pending, succeeded, and failed states so clients can distinguish a job that is still running from one that already failed.
Set a reasonable retention window on job status records so clients polling after a delay still get an answer instead of a 404.

Example

POST /api/reports HTTP/1.1
Host: api.example.com
Content-Type: application/json

{ "type": "annual-summary", "year": 2025 }

HTTP/1.1 202 Accepted
Location: /api/reports/jobs/9f21c
Content-Type: application/json

{ "jobId": "9f21c", "status": "queued" }

Report generation is queued; the client polls the job URL for completion.

Try it live

Our free status responder returns a real HTTP 202 you can point tests, monitors or a browser at.

GET https://mcp.httpstatus.com/status/202