> For the complete documentation index, see [llms.txt](https://docs.chord.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.chord.co/chord-oms/chord-storefront-event-tracking/the-chord-tracking-plan/custom-event-subscription-generated.md).

# Custom Event: Subscription Generated

## Custom Event: Subscription Generated

{% hint style="warning" %}
**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.
{% endhint %}

## 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       | 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)

{% hint style="info" %}
{ "user\_id": 2, "event": "Email Queued", "properties": { "email": "<customer@example.com>", "email\_name": "Email Subscription Generated", "email\_context": { "subscription\_id": 19, "actionable\_date": "02/06/2026", "interval\_length": 1, "interval\_units": "week", "products": \[ ... ], "prepaid": false, "prepaid\_subscription": {}, "converted\_from\_prepaid": true, "payment\_method\_name": "Stripe", "state": "active", "paused": false, "processing\_state": "pending" } } }
{% endhint %}

### 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.

1. In Iterable, create a journey triggered by the `Email Queued` event.
2. Filter to events where `email_name` equals `Email Subscription Generated`.
3. Split on `email_context.converted_from_prepaid`.
4. Route true to your conversion template, for example a renewal notice.
5. Route false to your new prepaid template, for example a gift or plan confirmation.
6. 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`.

1. In Chord OMS, go to **Webhooks** and open your endpoint.
2. Under **Events**, add `subscription_generated`.
3. 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.chord.co/chord-oms/chord-storefront-event-tracking/the-chord-tracking-plan/custom-event-subscription-generated.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.