HTTP 202 Accepted in AI Agent Workflows: How to Verify Completion

HTTP 202 Accepted means the server accepted a request for processing—not that the requested operation finished. An AI agent should preserve the original request record, identify the provider’s documented status-check mechanism, and inspect its operation state before reporting completion or starting dependent work. Do not repeat the write just because it is still running.

In ActionDock, two different responses can contain 202: the response that accepts an ActionDock job, and the external provider’s response stored in that job. A provider 202 can produce a terminal gateway job named succeeded while the provider operation is still incomplete. Read the provider receipt and operation state, not the job label alone.

What 202 establishes—and what it does not

RFC 9110, section 15.3.3, defines 202 as acceptance for processing without completed processing. The request might not ultimately be acted on. Its response should describe current status and identify or embed a status monitor.

This is a deliberately weaker promise than “the change is complete.” It does not establish that a resource is ready, a background task succeeded, or a downstream business process finished. The provider’s operation contract determines how to obtain that evidence.

Microsoft’s asynchronous request-reply pattern illustrates one design: return 202 with a Location status URL and Retry-After polling guidance. Those headers belong to that pattern or a provider’s documented contract; they are not mandatory fields on every HTTP 202 response.

Separate the three success signals

Keep the identifiers separate too. The ActionDock job ID identifies a gateway record. A provider operation ID identifies work in the external system. Neither is automatically interchangeable with a resource ID or a workflow ID.

How ActionDock records a provider 202

For integration.execute and integration.fetch, output.statusCode is the provider’s HTTP status, separate from the outer status used to submit or read a job. When the exchange and receipt recording succeed, a provider 202 produces ok: true and gateway status succeeded. The dashboard labels these integration receipts accepted by provider and keeps the technical job status in the expanded record.

If local completion recording fails after a write receives provider 202, the job can instead become execution_unknown, with the received response preserved under output.providerResponse. Inspect that receipt; the gateway’s uncertain record is not evidence that the provider rejected the operation.

The same boundary applies to job.succeeded events and signed callbacks: for a provider 202, they notify the caller about acceptance, not independently verified completion. Waking an agent on that event must not cause it to announce that the provider’s work is finished. The durable actions workflow separates gateway jobs from the caller’s longer-running workflow.

The current provider-result contract retains the body and selected headers: contentType, etag, lastModified, retryAfter, and xMsOperationId. The last two have deliberately narrow validation:

• retryAfter accepts up to ten decimal digits representing seconds, or a valid HTTP date, within a 128-character ASCII limit.
• xMsOperationId accepts a hyphenated UUID, not arbitrary operation tokens or URLs.
• Missing, duplicate, malformed, or oversized values become null; older saved receipts may omit these fields.

These values are provider claims, not independently verified outcomes. Header filtering does not redact sensitive content in the response body.

ActionDock does not retain Location, Operation-Location, or Azure-AsyncOperation response headers. It does not automatically follow a provider URL, poll an operation, schedule a retry, or replay an accepted write. If the provider requires metadata that the receipt does not retain, establish a compatible, authorized observation path before relying on that workflow.

Verify completion with an explicit read

The following is a caller-owned workflow recommendation, not an automatic ActionDock polling feature.

1. Preserve the acceptance evidence

Save the original ActionDock job ID, provider status, response body, and any validated operation identifier. Keep the original submission idempotency key. A repeated submission with that key and input retrieves the historical job; it does not ask the provider for updated progress.

Record which provider operation the workflow is waiting for. If you cannot identify it reliably, stop dependent work and investigate rather than guessing from a similar resource name.

2. Choose the provider’s documented status endpoint

For example, Microsoft Fabric’s operation-state API uses GET https://api.fabric.microsoft.com/v1/operations/{operationId}. Its examples show HTTP 200 with status: Running, and a separate response with status: Succeeded. Permissions are those required for the initiating operation. After success, its documentation directs callers to retrieve the operation result separately.

For a compatible, owner-configured ActionDock connection with base URL https://api.fabric.microsoft.com/, the integration.fetch input could have this shape. The UUID is illustrative:

{
  "connectionId": "<owner-configured connection UUID>",
  "path": "/v1/operations/00000000-0000-4000-8000-000000000042"
}

The owner must enable GET on the required path and supply a valid credential with the provider’s required permissions. Fabric credential setup and refresh are not built in, and this example is not a claim of a tested live Fabric integration.

Do not fetch an arbitrary URL from a response body or bypass the connection because a provider suggests another host. The explicit read still needs an active connection, an allowed method and path, and the normal destination and credential checks. A provider-returned URL is input to evaluate, not permission to send a credential there. ActionDock requests do not automatically follow redirects.

3. Inspect both the HTTP response and operation body

Wait for the read job, then inspect its provider status, ok, body, and documented operation state. A gateway read can reach succeeded after receiving a provider error response with ok: false; that is not a usable status observation. HTTP 200 can also be a perfectly successful observation of an unfinished operation.

Use the provider’s actual terminal-state definitions. A successful operation, a terminal provider failure, an unfamiliar state, and a failed status read require different decisions. Retrieve any required result or resource after terminal success; do not infer a final business outcome from a transport status alone.

For an owner-operated check, Connections → Test GET → Run GET creates one integration.fetch job for the selected path and query. Refresh result rereads that saved job; it does not send another GET to the provider. To observe later provider state, deliberately run another permitted read. The specific-resource check contract explains this distinction.

4. Bound the observation loop

Follow valid provider timing guidance, including Retry-After when supplied. Choose a maximum observation window, handle rate-limited status reads, and stop dependent work when progress cannot be established. These scheduling and escalation decisions belong to the calling workflow, not ActionDock’s gateway job runner.

An expired observation window means “completion not established,” not “the original write never happened.” Keep the original acceptance receipt and later read results together. For throttled reads, use the HTTP 429 guide; a wait instruction never authorizes another write.

Do not turn observation failure into write replay

A provider operation that is running, a status endpoint that is temporarily unavailable, and a write whose initial response was lost are different cases. The last requires reconciliation of the initial dispatch, not merely another progress check. In ActionDock, ambiguous write transport failures or provider 5xx responses can produce execution_unknown; follow the reconciliation procedure before considering a replacement write.

An accepted job’s gateway receipt does not change when a later provider status read reports success or failure. Track the provider outcome separately in the calling workflow. If a new write is justified after investigation, it needs a genuinely new proposal, a new idempotency key, and separate owner approval—not an automatic replay of the accepted request.

ActionDock controls only requests routed through its MCP or HTTP API. Its receipt is evidence of what the gateway observed, not an independent attestation of the provider’s current state or a guarantee of exactly-once execution.

Completion checklist

• Distinguish the outer ActionDock response from output.statusCode.
• Keep the gateway job ID and provider operation ID separately.
• Preserve the acceptance receipt without labeling it completion.
• Use a documented, owner-allowed status read rather than an arbitrary response URL.
• Check the operation body, not just HTTP 200 or gateway succeeded.
• Retrieve the final result or resource when the provider requires it.
• Bound polling and leave unresolved outcomes unresolved.
• Never repeat a write merely because completion has not yet been observed.

The safe transition is from accepted to provider completion verified under its contract. A 202 receipt begins that investigation; it does not finish it.