HTTP 202 Accepted – Free, Online, Private

What HTTP 202 means

202 says the server accepted the request for processing and the processing has not finished. There may not be a new resource yet. The body or a Link header should tell the client where to look for status, if anywhere. Treating 202 as success-and-done is how jobs are reported green while the queue is still full.

202 Accepted belongs to the 2xx successful class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 202

When you see HTTP 202 Accepted, stop on that exact status line. 202 Accepted means the request was queued, not that the work finished. The trace that usually produces it: The request was written to a queue and a worker has not run. The 2xx successful class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 202 when the work is asynchronous: a render, an import, a payment capture that a worker will finish. Include a status URL if the client can poll. If the work already finished, return 200 or 201. If you will not do the work, return an error, not 202.

How to fix HTTP 202

To fix HTTP 202, change the condition that made the server choose Accepted. Record that the job was accepted. Poll or subscribe to the status URL. Do not tell the user the work succeeded until a later response says so. Retrying the original request may enqueue another job. Retry only with an idempotency key, or poll the job you already have. If the log line is a different code, leave this page. The mix-up people make with 202 is this one: 201 means the resource exists now. 200 means the request finished. 102 means a WebDAV request is still open. 202 means this HTTP request is finished and the work is not.

• A client treated 202 as 200 and told the user the file was ready.
• The status URL was missing, so the client had no way to learn about failure.
• A retry of the original POST queued the job twice because nothing made the request idempotent.

An access log that only stores 202 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 202 AcceptedHTTP/1.1 202 Accepted
Location: /jobs/9f2
Content-Type: application/json

{"status":"queued"}

Location here points at the job, not at the finished artifact. The JSON says queued. When the worker finishes, GET /jobs/9f2 changes. The original 202 will not change, because that response is over.

What the client should do

Record that the job was accepted. Poll or subscribe to the status URL. Do not tell the user the work succeeded until a later response says so.

Do not cache 202 as the state of the job. The job resource has its own GET, and that GET should not be cached for long.

Retrying the original request may enqueue another job. Retry only with an idempotency key, or poll the job you already have.

Codes people confuse with HTTP 202

201 means the resource exists now. 200 means the request finished. 102 means a WebDAV request is still open. 202 means this HTTP request is finished and the work is not.