Skip to main content
GET
Read paginated results in original submission order.
string
required
Job identifier returned by submission.
integer
default:"0"
Zero-based offset, 0–100.
integer
default:"20"
Page size, 1–50.

Item results

Items remain in submission order (item_index starts at zero). Each has application_id, provider_field_id, status, attempts, started_at, completed_at, result, and error. New pending items have null result/error; queued items awaiting a retry may retain an error from an earlier attempt. Starting the next attempt clears that error. Treat status as authoritative. Succeeded items contain the same response structure as a single check. Failed items contain { code, message, retryable } under error. Read result.compliance for succeeded checks; item success does not imply compliance. Follow next_offset until it is null. You can read results before the job completes, but queued/processing items are not final. Save the results you need before the 30-day retention window ends. Responses use Cache-Control: no-store. The example below shows one pending item on the first page.

Errors

An invalid job UUID, offset, or limit returns 422 INVALID_REQUEST. An unknown, expired, or other-provider job returns 404 BULK_JOB_NOT_FOUND. HTTP 200 can contain failed items; see bulk item failures and retry examples. All routes can also return authentication, validation, rate-limit, and dependency errors. Use the error catalog and examples to choose a retry or correction. Keep X-Request-ID when present.