Events

The full catalog of emitted events. Names follow the <resource>.<fact> pattern; the payload's data field carries the resource serialized in the v1 API format or a lean reference object (documented per event). An endpoint with an empty event list receives all of them, including future events.

Each page below documents, event by event, when it fires and a complete sample payload:

Resource	Page	Events
Customers	person	person.created · person.updated · person.deleted · person.classification_changed
Charges	charge	charge.created · charge.updated · charge.deleted · charge.paid · charge.overdue
Agreements	agreement	agreement.created · agreement.updated · agreement.deleted · agreement.accepted · agreement.cancelled · agreement.broken (planned) · agreement.completed
Disputes	dispute	dispute.created · dispute.updated · dispute.resolved · dispute.cancelled
Tasks	task	task.created · task.updated · task.completed · task.deleted
Collection rules	collection_rule	collection_rule.created · collection_rule.updated · collection_rule.deleted
Templates	template	template.created · template.updated · template.deleted
Classifications	classification	classification.created · classification.updated · classification.deleted
Interactions	interaction	interaction.created
Notifications	notification	notification.sent · notification.delivered · notification.read · notification.failed
Negativations	negativation	negativation.review_required · negativation.registered · negativation.removed
Protests	protest	protest.review_required · protest.registered · protest.paid · protest.cancelled
Test	webhook.test	webhook.test (fired on demand, not subscribable)

The envelope

Every delivery uses the same envelope; only data varies:

{
  "event": "charge.paid",
  "timestamp": "2026-07-23T12:00:00.000Z",
  "organizationId": "0f7a3c1e-2b4d-4e6f-8a9b-1c2d3e4f5a6b",
  "data": { "...": "documented per event on the pages above" }
}

• timestamp is the moment the event occurred (not the send time — retries keep the same timestamp).
• The delivery headers (X-Webhook-Event, X-Webhook-Event-Id, X-Webhook-Delivery-Id, X-Webhook-Attempt, X-Webhook-Timestamp, X-Webhook-Signature) are described in the overview; signature verification, in Security.

Payload conventions

• Entity events (*.created, *.updated and the like) carry the full resource in data, including monetary fields as decimal strings ("1500.00") and dates in ISO 8601.
• Deletion events (*.deleted) carry only { "id": "<uuid>" } — deletion is logical (soft delete).
• Fact events (charge.paid, notification.delivered, negativation.registered...) carry a lean reference object with the relevant ids (chargeId, personId...) — fetch the full resource from the v1 API if you need more.
• New fields may be added at any time without notice; handle data tolerantly (ignore what you don't recognize).

Choosing what to subscribe to

For financial reconciliation, charge.paid, charge.overdue, agreement.* and protest.paid are usually enough. To mirror the full state into a system of yours, subscribe to everything (empty list) and handle by prefix. The *.review_required events are useful for plugging approvals into internal tools (Slack, service desk) without anyone watching the review queue.