HTTP 202 Accepted — What It Means & How to Use

HTTP 202 Accepted means the server has accepted the request for processing but has not completed it — used for async operations, batch jobs, and queued tasks.

What It Means

The HTTP 202 Accepted status code tells the client that the request has been received and understood, but the server has not finished processing it. The actual processing may not have started yet — it could be queued, scheduled, or delegated to a background worker. This is a commitment to process, not a guarantee of success.

The response typically includes a Location header pointing to a status endpoint where the client can poll for completion, or a JSON body with a job/task ID. The client should not assume the final outcome — a 202 could eventually lead to 200 OK, 201 Created, or even 500 Internal Server Error depending on the backend processing.

Unlike 200 OK which implies the response body is ready, 202 explicitly signals: “I have your request, check back later for the result.” This pattern is essential for operations that take longer than the typical HTTP timeout.

When It’s Sent

• Background job submission — a batch processing endpoint accepts a job and returns a job ID
• Report generation — the server starts generating a PDF or CSV report asynchronously
• Video transcoding — the server accepts a video file and begins encoding it in the background
• Email campaigns — a request to send thousands of emails is queued for delivery
• Data import/export — the server accepts a large dataset and processes it asynchronously

Real Example

curl -v -X POST \
  -H "Content-Type: application/json" \
  -d '{"user_ids": [1,2,3,4,5], "template": "welcome"}' \
  https://api.example.com/emails/send

Expected response:

> POST /emails/send HTTP/1.1
> Host: api.example.com
> Content-Type: application/json
> Content-Length: 56
>
< HTTP/1.1 202 Accepted
< Location: /jobs/email-job-789
< Content-Type: application/json
< Content-Length: 43
<
{"job_id":"email-job-789","status":"queued"}

The Location header tells the client where to poll for updates. The client can then GET /jobs/email-job-789 to check if processing is complete.

How to Debug

Client-Side

1. Extract the job ID — parse the Location header or response body for the tracking identifier
2. Poll the status endpoint — create a polling loop with exponential backoff (start at 1s, double up to 30s)
3. Set a maximum timeout — don’t poll forever; define a reasonable deadline for the async operation
4. Handle eventual results — be prepared for both success and failure outcomes from the async job

Server-Side

1. Verify the job queue — check that the job was enqueued and picked up by a worker
2. Check worker logs — look for errors in the background processing pipeline
3. Monitor queue depth — if the queue is growing, the workers may be overwhelmed
4. Test the status endpoint — make sure the job status GET endpoint works before the job completes

curl

# Submit the job
curl -s -D - -o /dev/null -X POST -d '{"user_ids":[1,2,3]}' \
  https://api.example.com/report/generate

# Poll for results (extract Location: header manually)
curl -s https://api.example.com/jobs/report-job-456

Common Causes

FAQ

Related Codes

• HTTP 200 OK — the final success response for a completed async job
• HTTP 201 Created — when a resource is created synchronously
• HTTP 204 No Content — when the async job is complete and there is no response body
• HTTP 503 Service Unavailable — when the server cannot accept new jobs