Skip to main content
Every delivery wraps its event in the envelope described in the Webhooks guide. This page lists the data object for each event type. Balance and transfer payloads identify the target with exactly one of participant_id or group_id, depending on whether the target is a participant or a group. The examples below show the participant form; the group form is identical with group_id in place of participant_id. For transfer.completed, the source field is source_participant_id or source_group_id. balance.credited / balance.debited
reference_id is present when the credit or settle was correlated to a hold. settle is present only for settle operations (credit with reference_id to AVAILABLE) and contains held_amount (total previously held) and delta (settle minus held; positive = over-capture, negative = under-capture). balance.expired
balance.held / balance.released
balance.voided
transfer.completed
The source uses exactly one of source_participant_id or source_group_id. Each entry in recipients contains exactly one of participant_id or group_id, along with the amount transferred to that recipient. Source and recipient types may differ (e.g., a participant can transfer to a group).
redemption.completed (instant amount redemption)
redemption.completed (instant catalog item redemption)
redemption.pending (amount redemption authorization)
redemption.pending (catalog item redemption authorization)
reservation_id identifies the ledger reservation backing the authorization. expires_at is the server-computed effective capture deadline, which can be earlier than the requested deadline when a backing lot expires first. Schedule fulfillment from this delivered value instead of calculating it from the request. Pending authorization events do not include status. The catalog shape also omits asset_id and amount. redemption.completed / redemption.failed / redemption.cancelled (pending amount-redemption resolution)
Pending-redemption resolution (catalog item redemption)
status is COMPLETED, FAILED, or CANCELLED. failure_reason appears when a fail or cancel request supplies one. Automatic timeout failures use failure_reason: "expired".
Successful capture emits redemption.completed without a balance.* event. Reconcile webhook-derived balance mirrors with participant balance and statement reads so HELD remains accurate.
redemption.reversed
reward.status_changed
previous_status is the status before the write. status is the status after. They are always different; a same-status write produces no event. event.reversed One entry per original award line, with the amounts the reversal requested, recovered, and could not recover:
participant.created
participant.tier_changed When the target is a participant:
When the target is a group:
When the target is a program:
level is null when a tier is removed (downgrade to base level).
Exactly one of participant_id, group_id, or program_id is present, depending on the target of the tier change. The SET_TIER rule action supports cross-targeting via the target field, so consumers should not assume this is always a participant.
program.funded / program.burned
event.completed
event.failed
error_code is included when the failure has a classified machine-readable code (e.g. participant_suspended, program_inactive); it is omitted for unclassified failures. The same code is persisted on the event resource, so you can branch on failure type without string-matching error. Some early validation failures (e.g. an unparseable payload) omit program_id.
For endpoint setup, signature verification, and retry behavior, see the Webhooks guide.