RMZ supports webhook event types for orders and subscriptions. Each webhook you create listens for a single event type.Documentation Index
Fetch the complete documentation index at: https://docs.rmz.gg/llms.txt
Use this file to discover all available pages before exploring further.
Available Events
| Event | Trigger |
|---|---|
order.created | A new order is placed in your store (after successful payment or for free orders) |
order.status.changed | An order’s status is updated (e.g., from pending to completed, or completed to cancelled) |
subscription.created | A new subscription is created for a customer |
subscription.activated | A subscription transitions from trialing to active |
subscription.renewed | A subscription is successfully renewed with payment |
subscription.renewal_failed | An auto-renewal payment attempt failed |
subscription.past_due | A subscription enters the past due state after a failed payment |
subscription.expired | A subscription has expired (terminal state) |
subscription.canceled | A subscription has been canceled |
subscription.paused | A subscription has been paused (auto-renewal stops, access retained until period end) |
subscription.unpaused | A paused subscription has been resumed (period extended by remaining days) |
subscription.resumed | A canceled subscription has been resumed before the period ended |
subscription.updated | A subscription has been updated (variant change, extension, etc.) |
Every subscription webhook payload includes an
external_customer_id field at data.subscription.external_customer_id. This is the identifier the merchant supplied when creating the checkout session — use it to correlate incoming webhooks back to your own user records. The value is null if it was not set at checkout, but the key is always present.order.created
Fired when a customer successfully places an order. This includes orders from all sources: the storefront, embed checkout, and the Storefront API. Common use cases:- Send a custom notification (Slack, Telegram, email)
- Sync the order to an external system (CRM, ERP, accounting)
- Trigger a fulfillment workflow
- Update inventory in an external system
- Log the sale for analytics
order.status.changed
Fired when an order’s status changes after the initial creation. This event is not triggered for the first status (order creation) — only for subsequent status updates. Common use cases:- Notify customers of shipping or delivery updates via your own channels
- Update external dashboards or reporting tools
- Trigger post-purchase workflows (e.g., send a review request after completion)
- Sync order status with third-party fulfillment systems
order.created, reflecting the current state of the order after the status change. The statuses array includes the complete status history.
Order Status Values
Thestatus field in the payload corresponds to these values:
| Status | Meaning |
|---|---|
| 1 | Waiting for Payment |
| 2 | Under Review |
| 3 | Processing |
| 4 | Completed |
| 5 | Cancelled |
| 6 | Refunded |
subscription.created
Fired when a new subscription is created for a customer, either through a storefront purchase or via the Merchant API checkout session. Common use cases:- Provision access to a service or SaaS product
- Send a welcome email to the new subscriber
- Sync the subscription to your billing system
- Log the event for analytics
subscription.activated
Fired when a subscription transitions fromtrialing to active, typically after a successful first payment at the end of a trial period.
Common use cases:
- Upgrade the customer from trial to full access
- Trigger a billing confirmation notification
- Update your CRM with the activation date
subscription.renewed
Fired when a subscription is successfully renewed with a payment charge. Common use cases:- Send a payment receipt to the customer
- Log the renewal for accounting
- Extend access in your external system
subscription.renewal_failed
Fired when an auto-renewal payment attempt fails. The subscription may be retried automatically. Common use cases:- Notify the customer to update their payment method
- Send a dunning email sequence
- Log the failure for monitoring
subscription.past_due
Fired when a subscription enters thepast_due state after the first failed payment attempt.
Common use cases:
- Trigger a dunning workflow
- Display a warning banner in your application
- Downgrade the customer to a limited access tier
subscription.expired
Fired when a subscription reaches its terminal expired state, either after all retry attempts are exhausted or when a non-renewing subscription period ends. Common use cases:- Revoke access to your service
- Send a win-back email
- Archive the subscription in your system
subscription.canceled
Fired when a subscription is canceled, either immediately or scheduled for end of period. Common use cases:- Log the cancellation reason
- Trigger a retention offer
- Schedule access revocation for end-of-period cancellations
When canceled with
end_of_period, the subscription status remains active and auto_renew is false until the period ends. The subscription will transition to expired when the period ends.subscription.paused
Fired when a subscription is paused by the customer or via the Merchant API. Auto-renewal is suspended, but access is retained until the period end. Common use cases:- Suspend provisioned resources or downgrade service level
- Log the pause for analytics
- Send a “we’ll miss you” email
When a subscription is paused,
is_active becomes false and auto-renewal stops. The remaining days at the time of pause are stored internally. When unpaused, the period is extended by those remaining days.subscription.unpaused
Fired when a paused subscription is resumed. The subscription returns toactive status and the billing period is extended by the number of days remaining when it was paused.
Common use cases:
- Re-provision access or restore service level
- Resume billing in your external system
- Send a “welcome back” notification
subscription.resumed
Fired when a canceled subscription is resumed before the current period ends. The subscription returns toactive status and auto-renewal is re-enabled.
Common use cases:
- Restore access that was scheduled for revocation
- Update your CRM to reflect the reactivation
- Cancel any scheduled access revocation
subscription.updated
Fired when a subscription is modified, such as a variant change (upgrade/downgrade) or a courtesy extension. Common use cases:- Update access level in your system for upgrades
- Schedule a downgrade for the next billing cycle
- Log the change for auditing
Choosing the Right Event
order.created
Use when you need to react to new sales — send notifications, sync to external systems, or trigger fulfillment.
order.status.changed
Use when you need to track order lifecycle — notify customers of updates, sync status changes, or trigger post-purchase workflows.
subscription.created
Use when you need to provision access for new subscribers or sync subscriptions to your system.
subscription.renewed
Use when you need to confirm recurring payments, send receipts, or extend access in external systems.
subscription.paused
Use when you need to suspend provisioned resources or pause billing in your system.
subscription.canceled
Use when you need to trigger retention flows or schedule access revocation.
subscription.expired
Use when you need to revoke access or trigger win-back campaigns.
You can create multiple webhooks for the same event with different URLs. For example, one webhook sending
subscription.renewed to your billing system and another sending it to a Slack channel.
