Webhooks deliver events from CRS to your backend over HTTPS. Whenever a credit alert lands on a user's file, identity verification completes, a bureau data refresh happens, or any other lifecycle event fires, we POST a JSON payload to the webhook URL you configure on your host. Webhooks are the right channel when you need server-to-server notification — to update your own database, trigger a downstream workflow, fan out to other systems, or kick off an outbound email or SMS that you control.
They're one of four delivery channels (alongside email, SMS, and push); for credit alerts all four can fire together so you decide whether to store the event server-side, push it to the user's device, or both. Below you'll find the configuration steps, the event types we send, the JSON payload shape, retry behavior, and how to use webhook alerts together with the Alerts API for a robust integration.
Webhooks are one of four notification channels (alongside email, SMS, and push). For credit alerts, all four channels fire together so you can decide whether to push the alert to the end user, store it server-side, or both. For account-lifecycle events (registration, identity result, account close), only the webhook channel fires.
Webhook types
| Type | Value | When it fires |
|---|---|---|
| New account | ACCNEW | User account created (web widget only) |
| Identity passed | IDPASS | User completed identity verification |
| Identity failed | IDFAIL | Identity verification failed |
| Identity thin file | IDTF | Insufficient credit history |
| Identity service outage | IDSVCOUT | Identity service unavailable |
| Identity service incomplete | IDSVCINC | Identity service partial result |
| Account registered | ACCREG | User passed identity and is enrolled for credit data |
| Registration failed | ACCREGFAIL | Identity passed but bureau enrollment failed — sent only when no bureau enrolled |
| Account closed | ACCCLOSED | User account closed (web widget only) |
| Account locked | ACCLOCKED | Account temporarily locked out |
| Login failed | ACCLOGINFAIL | Authentication failed (web widget only) |
| Credit alert | ACCALERT | Credit-file change detected (new account, inquiry, address change, …) |
| Score refreshed | SCOREREF | A bureau pushed updated score data |
| Report refreshed | REPORTREF | A bureau pushed updated report data |
| Error | ERROR | Platform error worth surfacing to the customer |
| Test | TEST | Test payload for integration validation |
On a multi-bureau host, a user whose enrollment succeeded with some bureaus but not all is enrolled, so they get ACCREG, not ACCREGFAIL. ACCREGFAIL means nothing enrolled anywhere and the user cannot read credit data at all.
IDTF is sent instead of ACCREGFAIL when nothing enrolled and every bureau gave the same reason: it holds no credit file for that identity. Re-submitting will not change that answer, so treat IDTF as a decision and ACCREGFAIL as worth retrying.