Custom Event: Subscription Generated
This is a custom event. Subscription Generated was created specifically for a custom prepaid subscription program. It is not part of Chord's standard event set, so not all Chord OMS stores will receive it.
Subscription Generated Event
Overview
Subscription Generated is the event Chord sends for prepaid subscriptions. It fires when a prepaid subscription is created and when a prepaid subscription converts to a recurring one. Standard subscriptions send Subscription Created instead.
Two fields tell you which case you are looking at:
Case | prepaid | converted_from_prepaid |
|---|---|---|
New prepaid subscription | true | false |
Prepaid converted to recurring | false | true |
Use these fields to send the right message, such as a gift confirmation for a new prepaid plan or a "your subscription now renews automatically" email after conversion.
When it fires
Chord picks one event per new subscription, based on its type. You never get both for the same subscription.
Subscription type | Event sent |
|---|---|
Standard recurring | Subscription Created |
New prepaid | Subscription Generated |
Recurring, converted from prepaid | Subscription Generated |
This applies to email events and analytics events. If you have flows triggered by Subscription Created, they will not run for prepaid or converted subscriptions. Add a Subscription Generated flow to cover them.
Event payload
The email event and the analytics event carry the same prepaid fields. Only the wrapper differs.
Channel | Event name | Where the prepaid fields are |
|---|---|---|
Email Queued, with email_name = Email Subscription Generated | properties.email_context | |
Analytics | Subscription Generated | properties |
Prepaid fields
Field | Type | Description |
|---|---|---|
prepaid | boolean | true if the subscription is currently prepaid |
converted_from_prepaid | boolean | true if the subscription started as prepaid and has converted to recurring |
prepaid_subscription | object | Prepaid plan details. Empty {} when there is no prepaid plan attached. |
prepaid_subscription includes: installment_count, quantity, state, gift, auto_redeem, redemption_method, redemption_code, start_date, gift_message_details, purchaser, recipient, single_installment_price, full_price,and recurring.
Customer name
All subscription events now include first_name and last_name in context.traits. These come from the customer's billing address. If there is no billing address, the fields are left out.
Example email payload (trimmed, test data)
Using it in Iterable
Trigger on Email Queued where email_name is Email Subscription Generated, then split on the prepaid fields to pick the template.
- In Iterable, create a journey triggered by the Email Queued event.
- Filter to events where email_name equals Email Subscription Generated.
- Split on email_context.converted_from_prepaid.
- Route true to your conversion template, for example a renewal notice.
- Route false to your new prepaid template, for example a gift or plan confirmation.
- Test both paths in a test environment before going live.
The same approach works in other tools that receive Chord email events. For analytics tools, use the Subscription Generated event and the same fields under properties.
Webhook topic
Subscribe to the subscription_generated topic to get a webhook when a prepaid subscription converts. It is separate from subscription_created.
- In Chord OMS, go to Webhooks and open your endpoint.
- Under Events, add subscription_generated.
- Click Update.
The webhook body includes the subscription payload, including converted_from_prepaid.
FAQ
Will my Subscription Created flows still run? Yes, for standard subscriptions. They will not run for new prepaid or converted subscriptions. Use Subscription Generated for those.
Can one subscription send both events? No. Each new subscription sends either Subscription Created or Subscription Generated.
Do I need to change anything to get the new fields? No. The prepaid fields and customer name traits are added automatically. No existing fields were removed or changed.
What if the customer has no billing address? first_name and last_name are left out of context.traits. Build a fallback into templates that use them.