Skip to main content
Webhook names are grouped by the record that changed. Prefer outcome events such as order.paid for fulfillment, and use broad updated events only when the application genuinely needs every mutation.

​
Customer and revenue lifecycle

​
Before payment: checkout

checkout.created

checkout.updated

checkout.expired

A session reached expiry without completing.

​
Customer identity and access snapshot

customer.created

A customer record now exists.

customer.updated

Stored customer details changed.

customer.deleted

The customer record was removed.

customer.state_changed

The combined access snapshot changed, including subscriptions or benefit grants.

​
Recurring relationship

subscription.created

A recurring relationship was created; this alone does not prove collection.

subscription.active

subscription.uncanceled

subscription.canceled

subscription.past_due

Collection failed and the customer may recover by replacing the payment method.

subscription.updated

Catch-all mutation signal also emitted around active, canceled, uncanceled, past-due, and revoked transitions.

order.created

Inspect billing_reason to distinguish purchase, subscription_create, subscription_cycle, and subscription_update. A renewal uses subscription_cycle.

subscription.revoked

​
Cancellation timelines

The default cancellation schedules the end of access at period end. Immediately after the customer or merchant requests it, Ruba emits:
  1. subscription.updated
  2. subscription.canceled
Both payloads show active with cancel_at_period_end: true. At period end, billing stops, benefits are removed, and Ruba emits:
  1. subscription.updated
  2. subscription.revoked
Those payloads show canceled. With immediate merchant revocation, the complete transition arrives together:
  1. subscription.updated
  2. subscription.canceled
  3. subscription.revoked
All three payloads describe the now-canceled subscription.

​
Renewal timeline

At the renewal boundary, enabled endpoints first receive:
  1. subscription.updated
  2. order.created
The subscription carries its new current_period_start and current_period_end. The pending order contains the upcoming-cycle amount plus any prior-period usage. After successful collection, Ruba emits:
  1. order.updated
  2. order.paid
Both contain the order in paid state. Fulfillment should normally key off order.paid, not the earlier pending record.

​
Collected transaction

order.created

order.paid

order.updated

order.refunded

​
Returned money

refund.created

refund.updated

​
Customer entitlement

benefit_grant.created

benefit_grant.updated

benefit_grant.revoked

​
Configuration lifecycle

​
Benefit definitions

benefit.created

benefit.updated

​
Product catalog

product.created

product.updated

​
Organization settings

organization.updated