Errors
The Verification API uses conventional HTTP status codes and JSON error bodies. Related: SLA and escalation · TroubleshootingHTTP status codes
Public integration endpoints most often return these codes:403 (Forbidden) and 409 (Conflict) are uncommon on the documented consumer routes; treat them as non-retryable if you see them.
Error response format
The
code values returned for general failures are HTTP_VALIDATION_FAILED, HTTP_BAD_REQUEST, AUTH_UNAUTHORIZED, AUTH_FORBIDDEN, HTTP_NOT_FOUND, HTTP_CONFLICT, HTTP_RATE_LIMITED, HTTP_SERVICE_UNAVAILABLE, HTTP_INTERNAL_ERROR, and HTTP_CLIENT_ERROR. code and requestId are additive: every other field is unchanged, and the examples below omit them for brevity. Ignore any fields you do not recognize.
Tracing a request
Send anx-request-id header (1–128 characters: letters, digits, ., _, :, -) and we use it as the request id, so the same id appears in your logs and ours. If you send none, or an invalid value, we generate one. Either way it is echoed in the x-request-id response header.
For validation errors with multiple issues:
Common error scenarios
Authentication errors (401)
Missing Authorization header:401 Unauthorized body. There is no separate “invalid or expired token” message.
Validation errors (400)
Missing required fields:EMPLOYMENT and EDUCATION are accepted. Any other value returns a validation error.
Order or search not found
Get order and Get specific search return HTTP200 with an error field in the body when a resource is not found. Check for the error field in addition to the status code.
Order not found:
Client handling
Check status codes
Retry logic
Retry transient errors (5xx, network issues) with exponential backoff. Do not retry 4xx — fix the request instead.
externalSearchId before retrying. See Quickstart — Production readiness.
