A subscriber joins by redeeming an access code against a paid plan.
When this fires
A subscriber redeems an access code against a plan with no trial window, gaining access to the project.
That is the only path that emits this event. A card, wallet, or crypto checkout emits subscription.activated and payment.succeeded, but no member.* join event at all. If the redeemed plan carries a trial, member.trial_joined fires instead of this event.
This event is access-code-only. Paid checkouts do not emit it. For a paying audience, use subscription.activated as the join signal.
Caveats
- The payload does not carry the subscriber's connected accounts. Resolve them with the member endpoint using data.subscriber_id, which embeds identities, one row per connected account with the connector key and the platform's own id.
- Resource-level grants emit separate member.resource_added events as the dispatcher processes each invite.
- This event always accompanies subscription.created and access_code.redeemed for the same subscription.
Related events
- subscription.activated: the paid-checkout join signal.
- subscription.created: fires alongside on this path.
- member.trial_joined: trial counterpart.
Headers
t=<unix seconds>,v1=<hex>: the HMAC-SHA256 of "<t>.<raw body>" under the endpoint's secret. Verify it before acting, and refuse a t more than 300 seconds from now. During a secret rotation a v0= signature under the previous secret may precede v1=.
The event's ULID, bare. The envelope's id is the same ULID prefixed evt_, so strip the prefix before comparing. Deduplicate on it: a retry carries the same id.
The event name, the same as the envelope's type.
Always application/json.
Always Subscriby-Webhooks/1.0.
Payload
Response
Your endpoint acknowledged the delivery. Any 2xx status within 30 seconds marks it delivered; the response body is ignored.
Changes
Webhooks have no change history: a webhook is keyed by its event name rather than a path and method, so no recorded change can name it.