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. You can also create a pull webhook and poll its pending items.

​
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

By default, 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.*.

​
Polling webhook items

For an integration that polls for events, use Create webhook with pull: true, your creditorId and the events you need. A public HTTP(S) url is still required when creating the webhook, but pull webhooks hold items in PENDING without POSTing them to that URL. Your API key needs read:webhooks to fetch items and write:webhooks to acknowledge them. Both operations are restricted to your creditor’s webhooks.
  1. Get webhook items with state=PENDING. Add webhookId to poll a specific webhook:
    The response contains an items array and pagination meta. Each item has an id, hookId, event, data and state. Process the event payload in item.data.
  2. After successfully processing an item, Patch webhook item using that item’s id and {"state":"SUCCESS"}:
    A successful update returns 200 with {}. The item no longer appears when filtering by state=PENDING.
  3. Fetch page 0 again after acknowledging the batch. Acknowledged items leave the pending results, so increasing the page number would skip items. Once no pending items remain, wait before polling again.
Keep processing idempotent using the webhook item’s id: if processing succeeds but acknowledgment fails, the item will appear again on the next poll. Leave an item pending if processing fails, so it can be retried.

​
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.