Skip to main content
This is the full catalog of events Pipecat Cloud can deliver to a webhook endpoint. Each section lists when an event fires and what its data payload carries.
The catalog holds an invariant worth relying on: an event type is offered only if it can actually fire. Nothing you can subscribe to is a placeholder.

The envelope

Every event arrives in the same envelope. Only data differs between event types.

Payload conventions

  • Entities are identified by an _id / _name pair, such as service_id plus service_name, rather than a bare noun.
  • Field names are snake_case.
  • Money is always *_cents, as a JSON number.
  • Enum-ish fields name the cause, not the event: reason on service.suspended says trial_exhausted, not suspended.
One documented exception. session.started sends the service name as service, not service_name. It shipped before this convention and has existing subscribers, so it stays as it is. If you correlate across event types, the two spellings mean the same thing.
Fields marked nullable below are always present and may be null. Fields marked optional are omitted entirely when they do not apply, so read them defensively.

Builds

build.started is best-effort and not guaranteed. Build status is reconciled periodically rather than streamed, so a build that finishes between two checks goes straight to a terminal state and emits only that event. Do not pair build.started with build.succeeded as an open/close bracket: a subscriber counting in-flight builds, or closing a tracing span opened on build.started, will leak on exactly the fastest builds. Treat the terminal events as authoritative.
build.succeeded

Deployments

A deploy that changes nothing emits nothing. When a deploy resolves to no configuration change, Pipecat Cloud records an audit version without creating a deployment or replacing pods, and sends no event. deployment.updated means pods were actually replaced.
deployment.updated

Services

service.resumed fires whenever a suspension is lifted, including when there is nothing to bring back up, so every service.suspended has a matching service.resumed. When both causes apply, trial_exhausted is reported: it is the more specific one, and the one you can resolve yourself by adding a payment method.
service.suspended

Spend

Thresholds re-arm each billing period, so an organization sitting at a zero limit receives one spend.limit_reached per cycle.
A limit of 0 is a deliberate kill switch, not a cleared limit, and does not fire spend.limit_cleared. That event means the limit was removed entirely, and carries only the limit that was in force beforehand.
spend.threshold_reached

Sessions

session.started

Organization

org.trial_ended means the trial ran out, not that it finished. Adding a payment method also ends a trial and deliberately does not send this event: subscribers alert on it, and a successful conversion is not an alert.
amount_due_cents is what is owed past the consumed credits, taken from the upcoming-invoice snapshot.

API keys

The key value is never included in any api_key.* payload. Use these events to drive an audit trail, not to distribute credentials.

Secrets

Removing a field emits secret.deleted with scope field, not secret.updated, so a subscriber mirroring which keys exist can tell a removal from a value change.
Secret values are never included in any secret.* payload.
secret.updated

Not in the catalog

Two event types you might expect are deliberately absent:
  • deployment.deleted is retired. Deployments are never destroyed, so it could never fire. An endpoint already subscribed to it keeps working, but nothing will ever arrive.
  • session.ended is not offered. Session end is recorded by a component outside the service that emits these events, so there is no hook point that could report it faithfully. It is deliberately absent rather than offered and silent.
To detect the end of a session today, use the Session API or your agent’s own instrumentation rather than waiting for a webhook.