All API errors are returned with a consistent JSON body and a stable SC-prefixed error code. Error codes are forward-compatible — once published, an SC code keeps its meaning, so client logic that switches on codes keeps working as the platform evolves. New error scenarios are assigned new codes; existing codes are never reassigned to a different meaning.
The reference below is grouped by category — authentication and tokens, user accounts, identity verification and enrollment, credit-data products, host and validation, rate limiting, and webhook delivery — so you can find the codes relevant to whichever endpoint you're integrating against. Each entry lists the code, the human-readable message, the typical HTTP status (where one is consistently mapped), and a short note describing when the platform raises it. Always route on codes, not on messages: message text may be refined for clarity over time, codes are stable.
Every error response carries the same structure:
{
"timestamp": 1705312200000,
"codes": ["SC302"],
"messages": ["User Identity Required"],
"details": []
}| Field | Type | Description |
|---|---|---|
timestamp | number | Unix epoch milliseconds when the error was generated |
codes | string[] | One or more SC codes describing the failure |
messages | string[] | Human-readable messages aligned by index with codes |
details | string[] | Optional context for the failure (validation issues, upstream messages, etc.) |
Most failures return a single code. Validation errors and upstream service failures may return multiple codes in one response.
Always route on codes, not on messages — message text may be refined for clarity over time, but codes are stable.