pass_series.* events

A holder reached the last date of their season, with the final attendance tallies.

When this fires

The last date on one holder's season ticket closed. Their season is over.

Fires per holder, not per series, because "finished" is a fact about a purchase: two people holding the same season reach its end on different dates when one of them bought in late.

This is the renewal signal. The tallies are the half worth acting on. A completion with two of ten attended is a churn signal; the same completion with ten of ten is a renewal one. If the creator linked a next season, the holders-only presale opens around the same moment; see pass_series.presale_opened.

Caveats

  • The subscription is expired at this point, which is normal and not a failure. A dated purchase ends when its dates run out.
  • passes_total is this holder's slate, not the plan's. A mid-season buyer received fewer dates for the same price and their totals reflect that.
  • passes_attended + passes_missed can be less than passes_total when some dates were already covered by passes the holder owned individually; those were not issued twice.
  • successor_plan_id being present does not mean the holder has been invited yet. The presale opens when the series retires, which is a separate event.
  • The plan itself is deactivated automatically once its last date has run for everybody. That arrives as plan.deactivated with reason: series_exhausted.

Related events

  • pass_series.leg_completed: each date along the way, including this one.
  • pass_series.presale_opened: the invitation to the next season.
  • plan.deactivated: the series taking itself off sale.
postWebhookpass_series.completed

Headers

SB-Signaturestring required

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

SB-Event-Idstring required

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.

SB-Event-Namestring required

The event name, the same as the envelope's type.

Content-Typestring required

Always application/json.

User-Agentstring required

Always Subscriby-Webhooks/1.0.

Payload

idstring required

A ULID unique to the event, prefixed evt_. Every retry carries the same id, so it is the key to deduplicate on.

type'pass_series.completed' required

The event name, always pass_series.completed here.

created_atstring date-time required

When the event was emitted, server time, ISO 8601.

api_versionstring required

The contract version of the payload shape, 2026-05-01 today. A breaking change to a shape ships under a new version.

project_idstring uuid nullable required

The project the event belongs to; null for team-scoped and billing events.

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.