Asynchronous verifications

Most verifications run asynchronously:

1. POST /v1/{usecase} validates the request, reserves credits and returns 202 with a job_id, a Location header (the poll URL) and Retry-After (seconds to wait).

2. GET /v1/{usecase}/{job_id} answers 202 while the job runs (code: job_running) and 200 with result once it is done. A terminal failure is a 4xx/5xx envelope with a code from the error catalog. A never-issued id, or another team's job id, is 404 not_found — job ids are never an oracle for other tenants. Results are retained for 10 days.

3. GET /v1/company and GET /v1/phone are synchronous and answer in the request.

A test-mode key reserves nothing at step 1, and its job is already complete when the 202 is returned, so step 2 answers 200 on the first poll — see Test mode.

Typical completion times are published per operation in x-typical-latency; the submit/poll pairing in x-polling; the four MCP tool annotations in x-mcp-annotations.