subscription.created

When this fires

Exactly two paths emit this event:

• Access-code redemption: a subscriber redeems a code against a plan.
• Cardless trial start: a subscriber begins a trial that took no payment method.

Both are zero-payment acquisitions. Every paid acquisition (every payment provider, both recurring subscriptions and one-time passes) emits subscription.activated instead, and never emits subscription.created.

This event does not fire for paid checkouts. A card, wallet, or crypto purchase emits subscription.activated instead. If you are building access control for a paying audience, subscribe to both.

The data keys differ by path. Absent keys are omitted entirely, not sent as null.

access_code carries the complete code. It is already consumed and cannot be redeemed again, but treat it as you would any other customer identifier and avoid logging it into systems you do not control.

Caveats

• Do not treat this as the universal "a subscription exists" signal. For paid projects it never fires. The reliable pattern is to subscribe to both subscription.created and subscription.activated and de-duplicate on data.subscription_id.
• The access-code path also emits access_code.redeemed and either member.joined or member.trial_joined for the same subscription.
• The cardless-trial path also emits subscription.trial_started and member.trial_joined.
• The POST /v1/webhook-endpoints/{endpoint}/test endpoint sends a synthetic subscription.created payload regardless of your project's payment configuration. A successful test does not prove this event will fire in production.

Related events

• subscription.activated: the paid-checkout equivalent.
• access_code.redeemed: fires alongside on the access-code path.
• subscription.trial_started: fires alongside on the cardless-trial path.

Header Parameters

The signed JSON envelope posted to your endpoint.

Response Body