Event catalog: webhook and feed event types
These are the events Roster sends to your webhook endpoint and returns in GET /v1/events (activity) and GET /v1/financial_events (donation.updated, donor.updated, refund.created and refund.updated), with the payload fields each one may carry. Every event type below arrives in an envelope with event_id, event_type, occurred_at, church_id, entity_id, livemode and payload; the four financial events also carry sequence. livemode is true for production events and false for sandbox events. The test delivery (webhook.test, sent by POST /v1/webhook_endpoints/{id}/test) is not a business event: it carries only event_id, event_type, occurred_at, livemode and payload, so type your receiver to accept it. entity_id is the enrollment ID for enrollment.*, the donor session ID for partner_session.*, the church ID for church.*, the donation ID for donation.updated, the donor ID for donor.updated and the refund ID for refund.*. The fields below are the permitted payload fields, not a guarantee that every event contains every field.
| Event type | Permitted payload fields |
|---|---|
donor.updated |
donor, church_id, revision |
donation.updated |
revision, id, church_id, enrollment_id, donor_id, method, currency, amount_minor, status, received_at, updated_at, transfers, residual_minor, return_details, donor, donor_data_status, refunded_minor, funds |
refund.created |
id, object, donation_id, church_id, amount_minor, currency, funds, status, pending_reason, reason, failure_reason, cancel_recurrence, metadata, created_at, updated_at |
refund.updated |
id, object, donation_id, church_id, amount_minor, currency, funds, status, pending_reason, reason, failure_reason, cancel_recurrence, metadata, created_at, updated_at |
partner_session.created |
donor_session_id, partner_id, church_id |
partner_session.opened |
donor_session_id |
partner_session.completed |
donor_session_id, enrollment_id |
partner_session.expired |
donor_session_id |
church.created |
church_id, name |
church.onboarded |
church_id |
enrollment.created |
enrollment_id, church_id, mode, value, reference, fund, funds |
enrollment.activated |
expected_amount, expected_cycle |
enrollment.updated |
mode, value |
enrollment.paused |
reason, resume_at |
enrollment.resumed |
resumed_from |
enrollment.cancel_requested |
No additional fields |
enrollment.cancelled |
cancellation_business_days, effective_at |
enrollment.terminated |
reason |
enrollment.onboarding_expired |
reason |
Use event reconciliation for checkpointing and webhooks for signature verification. Enrollment activation and expected amounts do not prove money was received. The activity feed at GET /v1/events excludes financial updates. Recover donation.updated and donor.updated (including authorized donor profile data and a sequence) through GET /v1/financial_events; see financial integration.
refund.created and refund.updated carry the whole refund, the same object GET /v1/refunds/{id} returns: refund.created when a refund is created, by you or by Roster, and refund.updated on every later change, a failure included. They go to the partner the donation came through, and donation.updated follows with refunded_minor once a refund succeeds. See refunds.
church.onboarded arrives once per church, the first time the church becomes ready for paycheck giving: the moment payout_ready turns true on GET /v1/churches/{id} and GET /v1/churches. For test churches that takes seconds. If the church later stops being ready, no event is sent; read payout_ready. Churches that were already ready before Roster started sending church.onboarded do not receive it. Today it is sent in the sandbox only; in production, read payout_ready.
