HTTP 202 Accepted: check the job, not just the response

Acceptance is a separate event from completion

HTTP 202 Accepted means the server has accepted a request for processing, but processing is not complete. The work may not have started and may later fail. A client should not treat this response as a finished export, successful crawl, or completed business action.

The service's documentation must explain how to observe the outcome. It may provide a job identifier, a status URL, a callback mechanism, or another workflow. HTTP 202 alone does not define the field names or guarantee a polling endpoint.

Read the response contract

HTTP/1.1 202 Accepted
Content-Type: application/json
 
{
  "jobId": "demo-42",
  "state": "queued",
  "statusUrl": "https://api.example.com/jobs/demo-42"
}

This is an illustrative protocol message, not an Arcvenza endpoint or a live API to call. The documentation domain and fields show one possible contract. Your implementation must use the actual service's documented response.

Preserve the job identifier with the original request context. Validate that a supplied status URL belongs to the expected service before following it, and apply only the authentication documented for that endpoint. Do not forward credentials to an arbitrary URL found in untrusted response content.

Track the job through explicit states

These state names are examples. Some services use different labels or combine states. Define terminal success and terminal failure according to the actual API instead of checking whether any response happens to contain the word done.

Poll with a stopping condition

Choose the maximum waiting time, allowed polling rate, and terminal states before starting. Follow documented Retry-After or polling guidance when it is provided. Network errors during polling do not automatically mean the underlying job failed.

When the waiting budget expires, store the job identifier and mark the outcome unresolved. Do not create another identical job automatically. The first job may still be running, and a duplicate can consume resources or repeat a state-changing action.

Recover without duplicating work

If the initial submission times out before you receive a job identifier, follow the service's documented idempotency or reconciliation method. A blind repeat may submit the same work twice. An idempotency header helps only when that particular API supports it and defines how it behaves.

If you already have a job identifier, resume its status check after a temporary client interruption. Retain the original scope and output requirements. Changing the request while continuing to label it as the same job makes later validation unreliable.

Validate output after terminal success

Consider an illustrative export request for three authorized pages. The POST returns 202 and the job later reports success. The client still needs to check whether the output contains the three intended records, the expected fields, and explicit outcomes for any failed pages.

A completed job with an empty file or an error page is not a usable deliverable. Compare the result with the acceptance rule written before submission. In Arcvenza's workflow, use the actual task status and logs available in its interface rather than assuming this example's endpoint or state labels are implemented. For browser-based crawl work, use the Crawler Console workflow when it fits the task.

FAQ and next action

Is 202 an HTTP error? No. It is a successful acceptance response, but the later work remains unresolved.

Does every 202 include a Location header? No. Follow the documented contract and response body. Review the HTTP error guide for polling failures, then inspect the real task workflow and output before increasing volume.

Technical references

MDN: 202 Accepted · RFC 9110: HTTP semantics

MDN: 202 Accepted · RFC 9110: HTTP semantics