Skip to main content

Events

The Events screen is the log of every domain event the account emits: the signals that say "this happened" (charge.paid, agreement.accepted, notification.delivered) for whoever needs to react to them. It is the same source that feeds the webhooks: what appears here is exactly what would have been (or was) delivered to a subscribing endpoint.

Domain event log

What it is for​

It is the integrator's screen. Before configuring a webhook, here you see which events the account is actually emitting and the format of each payload. After configuring, it is where you check whether the event you expected was really emitted, without relying on your own system's log.

What each row shows​

  • When — the moment the event occurred.
  • Type — the event name in the <resource>.<fact> pattern (charge.paid, dispute.resolved, person.created).
  • Resource — the type and identifier of the affected resource (charge, customer, agreement, etc.).
  • View payload — opens a dialog with the event's full body in JSON, the same object the webhook would deliver.

Filters​

  • By type — type part of the event name (for example, charge.paid or just charge.) to filter.
  • By resource — choose the resource type (Charge, Customer, Agreement, Dispute, Task, Rule, Template, Classification, Interaction, Credit bureau registration, Protest, Webhook).

The full catalog of events, with when each one fires and sample payloads, is in Webhook events. Configuration and delivery to endpoints are in the Webhooks overview.

Events vs. Audit​

Two similar trails that answer different questions:

  • The Audit is the immutable trail of user actions: who did what, when, from which IP, with the state before and after. It is legal evidence, built to answer "why did you do this?". It cannot be altered or deleted.
  • Events (this screen) are domain signals for integration: what happened in the system, in the format a webhook consumes. The focus is machine reading machine, not the proof of a human action.

An example makes it clear: when an operator resolves a dispute, the audit records their action (with reason, IP, before/after) and, in parallel, a dispute.resolved event is emitted for whoever is listening. Same resolution, two records with distinct purposes.