202 Accepted
The request has been accepted for processing, but the processing has not been completed.
Meaning & Description
Common Causes
- The server successfully validated and queued an asynchronous task.
How to fix a 202 error
- Check the response body or Location header for a URL to poll the job status.
- Verify that your client implements an appropriate polling or webhook mechanism to retrieve the final result.
- If the final job fails, check the logs of the background worker, as the initial 202 response means the HTTP layer succeeded.
Browser & SEO Behaviour
Browser Behavior
Browsers treat this as a standard successful response. They will not automatically poll the Location header.
SEO Impact
Neutral. Seldom encountered by crawlers.
CDN Behavior
Generally not cached since it pertains to a specific async operation state.
Code Examples
HTTP/1.1 202 Accepted
Date: Mon, 23 May 2026 22:38:34 GMT
Content-Type: application/json
Location: /api/jobs/998877
{"jobId": "998877", "status": "pending"}app.post('/api/reports', async (req, res) => {
const jobId = await backgroundQueue.add('generate-report', req.body);
res.status(202).json({
message: 'Report generation started',
jobId,
statusUrl: `/api/jobs/${jobId}`
});
});from fastapi import FastAPI, BackgroundTasks, status
app = FastAPI()
def process_video(video_id: str):
pass # Long running task
@app.post("/api/videos", status_code=status.HTTP_202_ACCEPTED)
def upload_video(background_tasks: BackgroundTasks):
video_id = "v_123"
background_tasks.add_task(process_video, video_id)
return {"status": "processing", "job_id": video_id}func handleAsync(w http.ResponseWriter, r *http.Request) {
jobID := enqueueJob()
w.Header().Set("Location", "/api/status/" + jobID)
w.Header().Set("Content-Type", "application/json")
w.WriteHeader(http.StatusAccepted)
w.Write([]byte(`{"status": "queued"}`))
}[HttpPost]
public IActionResult QueueTask()
{
var jobId = Guid.NewGuid();
_queue.Enqueue(jobId);
return Accepted($"/api/jobs/{jobId}", new { status = "queued", id = jobId });
}curl -X POST https://api.example.com/export \
-H "Authorization: Bearer token" -iRaw HTTP Response Example
HTTP/1.1 202 Accepted
Date: Mon, 23 May 2026 22:38:34 GMT
Location: /api/exports/status/job-123
Content-Type: application/json
Content-Length: 75
{"jobId": "job-123", "status": "processing", "estimatedCompletion": "5m"}Real-world Examples
Frequently Asked Questions
How does the client know when the job is done?
The server should provide a way to check the status. This is usually done by including a URL in the Location header or the response body that the client can poll. Alternatively, the client can provide a webhook URL for the server to call upon completion.
Is a 202 Accepted a guarantee that the request will succeed?
No. It only guarantees that the request was valid and has been queued. The background process could still fail due to bad data, timeouts, or system errors.
What HTTP status should the polling endpoint return?
While the job is still running, the polling endpoint typically returns 200 OK with a JSON body indicating "status: pending". Once complete, it can return 200 OK with the result, or a 303 See Other redirecting to the final resource.
Can I use 202 Accepted for webhooks?
Yes, 202 Accepted is the perfect response for webhook receivers. It tells the sender "I received your payload, stop retrying," allowing your system to process the webhook payload asynchronously.
Should 202 Accepted have a response body?
Yes, it is highly recommended. The body should contain a human or machine-readable status, a job identifier, and instructions on how to check the final outcome.
Did You Know?
In enterprise integration patterns, the 202 Accepted status is the cornerstone of the "Asynchronous Request-Reply" pattern.
It explicitly breaks the typical synchronous HTTP request-response cycle, acknowledging that HTTP was not built for long-lived connections.
Developer Tips
- Never make users stare at a loading spinner for more than 5 seconds. If an operation takes longer, switch to returning a 202 Accepted and poll for the result.
- Always return a correlation ID or Job ID in your 202 response so the client has a reference to the queued work.
- For webhook handlers, always parse the JSON, push it to a queue, and immediately return 202. Do the heavy lifting in a separate worker process to prevent webhook timeouts.
Interview Questions
These are questions you might face in a backend or API design interview that touch on HTTP 202.
How do you handle an API request that takes 3 minutes to process?
I would implement an asynchronous pattern. The initial request would validate the payload, add the task to a message queue (like Redis/RabbitMQ), and immediately return a 202 Accepted status. The response would include a Location header or job ID. The client can then poll a separate status endpoint using that ID to check when the job completes.
What is the difference between 200 OK and 202 Accepted?
200 OK means the request was fully processed and the final result is in the response. 202 Accepted means the request was valid and queued, but processing is happening in the background and is not yet complete.
Common Interview Mistakes
- Suggesting that the client should just keep the HTTP connection open for 10 minutes until the server finishes. This leads to dropped connections, proxy timeouts, and exhausted server threads.
- Assuming that receiving a 202 means the final outcome is guaranteed to be successful.