A member row was created as a lead.
When this fires
Somebody the project had never seen opened its bot, arrived through a Smart Link or a referral link, signed in to its portal or wrote to its support, and a member row was created for them with the status lead. It fires once per row, whichever door they came through, the moment the row is written; it never fires for a connected account adopted from a sibling project or linked by a backfill, because nobody just walked in. The lead sequences of Lead nurture enrol the member on the same event.
Caveats
- The payload carries no name and no connected account. Resolve the member with the member endpoint using data.subscriber_id.
- A lead who buys later raises subscription.activated (a paid checkout) or subscription.created (an access code or a cardless trial) with the same subscriber_id; a lead who leaves without buying raises nothing more.
Related events
- sequence.enrolled: the lead sequences the arrival enrols the member in, with trigger lead.
- subscription.activated: the paid-checkout join signal.
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.