What does a 202 HTTP response mean?

HTTP 202 Accepted means the server received your request and accepted it for processing, but processing was not finished at the time of the response. It is non-committal: the work may still fail, and HTTP has no way to send a later status update for that original request MDN: 202 Accepted.

201 vs 202: the quick distinction

• 201 Created: the server finished creating a new resource before sending the response. Return the resource (or a description) and its URL, often in a Location header MDN: 201 Created.
• 202 Accepted: the server accepted the request but deferred the work. The outcome is not yet known and may not succeed MDN: 202 Accepted.

When to return 202 Accepted

Choose 202 when:

• Processing is offloaded to a background job, another service, or a batch window, so the result is not immediately available MDN: 202 Accepted.
• You need to acknowledge receipt quickly (for example, a large export, long-running report, or queue submission), and completion may take seconds or minutes.
• You cannot guarantee success at response time. 202 communicates acceptance without implying completion MDN: 202 Accepted.

Practical tip: include a way for the client to track progress, such as a status URL in the body. A common pattern is to also include a Location header pointing to a status monitor the client polls HTTP.dev: 202 Accepted. Because HTTP cannot send a later status for the original request, the client must follow up itself MDN: 202 Accepted.

Worked example: 201 now vs 202 later

Synchronous creation (201 Created)

POST /users HTTP/1.1
Content-Type: application/json

{"email":"brian.smith@example.com"}

HTTP/1.1 201 Created
Content-Type: application/json
Location: https://api.example.com/users/123

{
  "id": 123,
  "email": "brian.smith@example.com"
}

The resource exists before the response and is addressable now, which matches 201 semantics MDN: 201 Created.

Asynchronous job (202 Accepted)

POST /exports HTTP/1.1
Content-Type: application/json

{"type":"sales","range":"2026-Q1"}

HTTP/1.1 202 Accepted
Content-Type: application/json
Location: https://api.example.com/jobs/9f3a

{
  "jobId": "9f3a",
  "statusUrl": "https://api.example.com/jobs/9f3a",
  "status": "pending"
}

GET /jobs/9f3a HTTP/1.1

HTTP/1.1 200 OK
Content-Type: application/json

{
  "jobId": "9f3a",
  "status": "succeeded",
  "resultUrl": "https://api.example.com/exports/9f3a"
}

The 202 only acknowledges acceptance. The client polls the status URL (from the body and commonly the Location header) until a terminal state is available MDN: 202 Accepted HTTP.dev: 202 Accepted.

How clients should handle 202

• Do not treat 202 as final success. It is an acceptance-only response; the eventual outcome may be failure MDN: 202 Accepted.
• Follow the provided status URL and poll until you reach a terminal state your API documents (for example, succeeded, failed, or canceled). Use modest backoff and respect any Retry-After header if present HTTP.dev: 202 Accepted.
• If your platform supports callbacks, consider replacing polling with a webhook to receive a completion notification. For a broader comparison of push vs pull, see What are the differences between REST APIs and webhooks?
• Avoid resubmitting the original request while a job is in progress. If you must support safe retries, design for idempotency so duplicates are not created; see What is an idempotency key in APIs?

Decide between 201 and 202 for this endpoint

• Is the resource fully created and addressable now? Return 201 Created and include its URL (Location header recommended).
• Is work queued/deferred and the outcome unknown at response time? Return 202 Accepted.
• When returning 202, include a status URL (in the body, and optionally Location) that clients can poll.
• Document terminal states and what the client should do when each state is reached.

Common mistakes to avoid

• Using 202 for already-completed operations. If the result exists now, prefer 201 (creation) or 200/204 (other success) MDN: 201 Created MDN: 202 Accepted.
• Implying that 202 guarantees success. It does not; the processing may not have started yet and can still be disallowed or fail MDN: 202 Accepted.
• Returning 202 without giving clients a way to track progress. Provide a status endpoint and describe how to detect completion MDN: 202 Accepted.

FAQ

Does 202 mean success? No. It only confirms the server accepted the request for processing; the final outcome is not known at response time MDN: 202 Accepted.

When should I choose 201 instead of 202? Use 201 when the resource is created before the response is sent and you can supply its URL. Use 202 when you defer the work and cannot confirm completion yet MDN: 201 Created MDN: 202 Accepted.