Event Reference

The canonical, machine-readable event list is published at:

GET https://api.subscriby.net/webhook-events.json

The JSON is regenerated on every Subscriby deploy. The per-family pages below duplicate the same source with explanatory prose and payload samples.

Families

Envelope shape

Every event has the same outer shape:

{
  "id": "evt_01HXDELIVERY000000000TST",
  "type": "subscription.activated",
  "created_at": "2026-05-18T10:05:00Z",
  "api_version": "2026-05-01",
  "project_id": "7f3d1c92-8b45-4e6a-9d21-5c8e0a4b6f13",
  "data": {
    "subscription_id": "5b7e2d40-1a86-4c39-97f2-e83d0b16c5a4",
    "plan_id": "c4e82f16-93a7-4d5b-b81c-6e0f27a94d3b",
    "subscriber_id": "2a91c4e7-6f38-4b52-8e0d-9c1a7b3f5d80",
    "provider": "stripe"
  }
}

• id — ULID unique per event. Use for consumer-side de-dup.
• type — the canonical event name (matches SB-Event-Name header).
• created_at — ISO 8601 UTC.
• api_version — see versioning.
• project_id — which project the event belongs to (null for team-scoped or billing events).
• data — event-specific payload; the per-family pages describe each shape.

data is flat for subscription, payment, member-lifecycle, and access-code events — subscription_id, plan_id, subscriber_id as sibling keys, not nested subscription / subscriber / plan objects. A few families do nest a single snapshot object: project.* nests project, plan.* nests plan, project.resource.* nests resource, project.payment_method.* nests payment_method, support.canned_reply.* nests canned_reply, support.settings.updated nests settings, and the member moderation events (banned, unbanned, kicked, removed) nest subscriber. Every updated event in those families also carries a changes map of {field: {from, to}} listing only what mutated. The coupon.* family is split down the middle: the five lifecycle events (created, updated, activated, deactivated, deleted) nest coupon, while coupon.redeemed and coupon.exhausted are flat, because they describe a transaction rather than the code. No payload in any family contains a subscriber email or name — resolve those from the API using subscriber_id.

Keys that do not apply to a given emission path are omitted entirely rather than sent as null. Write consumers defensively: check for key presence, don't assume a null placeholder.

Subscribing to events

• Programmatic: POST /v1/webhook-endpoints with events: ["subscription.created", ...].
• Dashboard: Settings → Webhooks → New endpoint.
• Zapier: each trigger maps 1:1 to a single event and subscribes behind the scenes.