Async Execution
Send Prefer: respond-async with POST /v1/validation when your integration can accept work that finishes later.
| POST result | Meaning | Next step |
|---|---|---|
200 completed | Validation finished within the synchronous window. | Read the result. |
202 in_progress | Validation was accepted and remains active at the sync boundary. | Save validation_id and retrieve it with GET. |
202 is accepted, not completed, and is not an error. Its body contains validation_id and status: "in_progress". Its headers include Location, Retry-After: 1, Preference-Applied: respond-async, and Cache-Control: no-store.
GET /v1/validation/{validation_id} returns HTTP 200 with in_progress, completed, or sanitized failed state. Respect Retry-After before a later retrieval. The examples make an explicit single GET and do not automatically poll.
Execution timing
Hybrid-capable execution uses a 20-second sync wait, 60-second provider execution budget, and 90-second hard execution deadline. Sending the preference does not force a 202: fast results still return 200.
Without Prefer: respond-async, the API retains synchronous qualified compatibility with a 20-second provider timeout. This is the same product with synchronous transport. Client transport timeouts are separate from these execution budgets.
New production organizations receive hybrid capability by default. The preference accepts async transport; it does not choose an evaluator or grant organization policy.
Failures and identity
A timeout or lost connection can leave the outcome unknown. Keep the original request and idempotency key. Retrieve by ID when available; otherwise use deliberate same-key replay according to Idempotency.
In-progress work, polling, completed replay, and failed execution add zero Validation Units. Completion and usage accounting are atomic.