This glossary explains what each Collection Partner webhook event means in business terms - when it fires and what it signals about a case assigned to your agency, or about a case your firm manages for its own client. For payload schemas, signature verification, and endpoint setup, see Developer Docs.
Event overview
For cases assigned to your agency, Debitura sends seven webhook event types, covering case lifecycle, payments, and chat. A firm that also submits cases for its own clients as a managing partner can opt in to a separate set of eight managed_case events for those cases - see Events for cases you manage below.
Event | Category | What it signals |
case.assigned | Case lifecycle | A case was assigned to your agency |
case.updated | Case lifecycle | An assigned case changed lifecycle state |
case.closed | Case lifecycle | An assigned case was closed |
case.declined | Case lifecycle | An auto-assigned case was declined by an Exclusive partner |
payment.created | Payments | A payment was registered on an assigned case |
payment.deleted | Payments | A previously-recorded payment on an assigned case was removed |
chat.created | Communication | A new chat message was posted on an assigned case |
Case lifecycle events
These events track a case from the moment it reaches your agency through to closure. Each payload identifies the case by its reference number.
case.assigned
When it fires: A case has been validated by Debitura and assigned to your agency. This is the entry point for your involvement with the case.
What it means: A new case is now yours to work. You receive case.assigned rather than case.created because the creditor created the case; assignment happens only after Debitura validates and routes it, which can be hours or days later.
What to do: Record the case in your system using its reference, review the details, and begin work. The payload includes the case reference and the current lifecycle state (typically Active).
case.updated
When it fires: An assigned case changes lifecycle state.
What it means: The case has moved forward or backward in its lifecycle. The payload includes both the previous and the new state.
What to do: Update the case status in your system to match the new state. See Case lifecycle (deep dive) for what each state means.
case.closed
When it fires: An assigned case is closed.
What it means: Collection activity on the case has ended. The payload's closeCode indicates the outcome (for example, Paid).
What to do: Mark the case as closed in your system. The closeCode uses the same set as the platform close codes - see Case close codes.
case.declined
When it fires: An assigned case is declined by your agency. This event applies only to Exclusive partners declining an auto-assigned case. Legal Network partners who choose not to quote on a lead use a separate lead flow and never receive this event.
What it means: You rejected the case and it is removed from your queue. What happens next depends on the decline. If you declined because the debtor is insolvent, dissolved or no longer trading, and confirmed that this is the case now, the case closes as Debtor Insolvent/Bankrupt and is not offered to the partner network. Other valid declines follow the ordinary sharing rule: the case is released to the partner network as an open lead for other eligible partners to quote on only when the client has sharing enabled and the case is not managed by another partner; otherwise it closes as Case never started. It is never automatically reassigned to one specific partner.
What to do: Remove the case from your active work queue if you had already recorded it as assigned.
Payment events
payment.created
When it fires: A payment is registered on a case assigned to you.
What it means: Money has been recorded against the debt.
What to do: Reconcile the payment in your own system and update the outstanding balance for the case.
payment.deleted
When it fires: A previously-recorded payment on one of your assigned cases is removed (for example, entered in error).
What it means: The payment recorded earlier no longer stands.
What to do: Reconcile - reduce or reverse the corresponding entry in your own system.
Communication events
chat.created
When it fires: A new chat message is created on a case assigned to you.
What it means: There is a new message in the case communication thread.
What to do: Read the message and respond in the case chat where needed, so the conversation stays on record.
Events for cases you manage (managing partners)
If your firm also submits cases for its own clients as a managing partner, you can receive a separate set of eight managed_case events about the cases your firm currently manages. They are separate from the seven events above, which cover cases assigned to your agency for collection.
Event | Category | What it signals |
managed_case.created | Case lifecycle | A case your firm submitted for a client was created |
managed_case.assigned | Case lifecycle | A collection partner was assigned to a case you manage. This does not prove that Debitura has finished checking the case. |
managed_case.updated | Case lifecycle | A case you manage changed lifecycle state. The old and new state can be the same, and there is no separate event for a change of collection partner. |
managed_case.closed | Case lifecycle | A case you manage was closed, with its close code |
managed_case.declined | Case lifecycle | The collection partner declined a case you manage. The case closes as Case never started, or as Debtor Insolvent/Bankrupt when the partner confirmed the debtor is insolvent, dissolved or no longer trading now. |
managed_case.payment.created | Payments | A payment was registered on a case you manage |
managed_case.payment.deleted | Payments | A previously recorded payment on a case you manage was removed |
managed_case.chat.created | Communication | A new chat message was posted on a case you manage (the notification does not include the message text) |
Opt-in by name: you must select each managed_case event by its exact name in your subscription. Existing subscriptions are not opted in automatically.
Notifications, not copies of the case: they carry identifiers, status and payment facts only - no chat text, no close or decline comments, no client or debtor contact details and no documents.
Test and live stay separate: a live subscription only receives events for live cases, and a test subscription only for test cases.
Order is not guaranteed: events can arrive out of order.
For setup and exact timing, see Developer Docs: Webhooks - managing-role events. For the managing partner role itself, see Managing partner role.
Managing your subscription
You subscribe by registering an HTTPS endpoint together with the list of event types you want to receive. A test mode option lets you receive events from test cases only while you build and validate your integration, before switching to live production events.
Debitura automatically retries failed deliveries, and an endpoint that keeps failing is disabled until you fix it and re-enable it. For the exact setup, payload schemas, signature verification, retry and re-enable behaviour, and the endpoint reference, see Developer Docs.
Developer Docs: Developers: for endpoint setup, payload schemas, and signature verification, see Developer Docs: Webhooks and the Collection Partner API reference.