Skip to main content
The endpoints in this reference let you push data into the platform and read it back. Webhooks are the other direction: Debbie calls an endpoint of yours when something happens on one of your cases, so your system does not have to poll for it.

​
Setting one up

Add a webhook in the creditor portal under Developers → Webhooks, or with Create webhook. You give it a URL and the list of events you want. A webhook you create is bound to your creditor and only ever receives events for your own cases — there is nothing to filter on your side.

​
Delivery

Every delivery is a POST with a JSON body of the shape:
  • Debbie sends an X-Verification-Token header with the token issued when the webhook was created. Verify it on every request before acting on the payload.
  • Any non-2xx response counts as a failure. The first delivery is attempted immediately; a failure is then retried up to 7 more times with exponential backoff — roughly 1, 3, 8, 21, 55, 149 and 404 minutes after the previous attempt, about eleven hours end to end.
  • Respond quickly and process asynchronously. Acknowledge with 200 as soon as the payload is persisted rather than after your own downstream work has finished.
  • Retries mean a delivery can arrive more than once with an unchanged body, so make the handler idempotent. Key it on the identifiers the event carries: billingId for billings.create, and caseId — together with status — for cases.*.

​
Events

These four are the only events a creditor webhook can subscribe to today.
There is no event for a payment landing on a case. Payments reach your books through the settlement — billings.create and the two endpoints in the Settlements guide — and the creditor portal shows them as they come in. If being notified per payment matters to your integration, tell your debt collection partner.