How to Track an Asynchronous Job After HTTP 202

202 separates acceptance from completion

A server need not keep a connection open until a long export or bulk conversion finishes. HTTP 202 Accepted means a request has been accepted for processing, but processing is not complete. RFC 9110 calls the response intentionally noncommittal because the work might later be disallowed. Show “accepted” or “processing,” not “complete.” IETF RFC 9110 §15.3.3 MDN Web Docs, 202 Accepted

Include a way to check status

The representation accompanying a 202 ought to describe the current status and point to a monitor that can estimate when the request will be fulfilled. One implementation could return a job ID and a URL such as /jobs/{id}, with states like queued, running, succeeded, and failed. HTTP does not prescribe that URL shape or those state names.

Keep status retrieval separate from submission. Return useful information such as the last update, result, or failure reason, and authorize each lookup so a guessable job ID cannot expose another user's result.

Set polling intervals in the API contract

Frequent polling creates traffic while a job is slow. A client can wait before its first check and increase the interval while work continues, or follow timing guidance explicitly provided by the service. RFC 9110 defines Retry-After for expected unavailability with 503 and the minimum wait requested before a 3xx redirected request. It does not set a polling interval for 202. Document the meaning and units of any API-specific hint. IETF RFC 9110 §10.2.3

A lost connection does not reveal the outcome

The server may continue after returning 202 and closing the connection. Acceptance also does not guarantee eventual success. If a status request times out, do not infer success or failure; query again with the same job ID. If the original submission response was lost, the client cannot tell whether the server accepted the work. Preventing a retry from creating a second job requires a separate duplicate-submission policy. RFC 9110 says HTTP has no facility for returning the asynchronous result on the original connection later.

A useful status representation answers what the client can do next, not merely whether the task is still running. An API might expose a task identifier, state, last-updated time, and a result link only after completion. These are design choices, not fields mandated by RFC 9110. If the service publishes an estimated completion time, it should describe it as an estimate and explain when it may change. Clients can then distinguish a documented pending state from a final result without inventing their own interpretation.

The status resource also has its own authorization and lifecycle questions. Possession of a job URL should not automatically reveal another user’s output; check access for both status and result retrieval. Decide how long records remain available, what an expired URL returns, and how a retried submission relates to an earlier task. A lost submission response differs from a failed status lookup: in the first case the client may not know whether work was accepted, while in the second the outcome remains unknown. Idempotency keys or a documented recovery flow can help manage that uncertainty, but 202 itself defines neither mechanism.

Expert documentation and the standard’s scope

RFC 9110, edited by Roy T. Fielding, Mark Nottingham, and Julian Reschke, is the normative specification for HTTP semantics. It establishes that 202 means accepted but unfinished processing and recommends describing current status and pointing to a monitor. It does not choose the queue, polling interval, retention period, cancellation behavior, or duplicate-submission policy. Those belong in the API contract and should reflect processing time, cost, and security needs.

Sources

IETF, RFC 9110: HTTP Semantics, §§15.3.3 and 10.2.3 MDN Web Docs: 202 Accepted