IntegrationsWebhooks
Overview
Managed webhook endpoints on Kaiten Cloud — subscribe an HTTPS endpoint to any of the 55 domain events, with signed deliveries, retries, and a delivery history. Self-hosted stacks consume the same events from RabbitMQ.
Every change to the Kaiten model, and every decision Kaiten makes, is a domain event — CUSTOMER_CREATED, LICENSE_ENTITLEMENT_ASSIGNED, INSTANCE_ENTITLEMENT_USAGE_REACHED. The event is written in the same database transaction as the change it describes, so the stream is complete by construction. How that stream reaches you depends on your edition.
Two paths to the same events
| Kaiten Cloud Kaiten Cloud | Self-hosted (Community Edition) | |
|---|---|---|
| Transport | Managed webhook endpoints — Kaiten delivers each event to the HTTPS URLs you register, signs the delivery, retries failures, and keeps a delivery history | The event stream itself — your consumer binds to the kaiten.events exchange on the RabbitMQ your stack runs |
| Body | The published contract: { "name", "type", "data" }, plus an optional headers object of metadata | One CloudEvents message per event, carrying the same fields as the outbox row's columns |
| Documented in | This section | Consuming events |
The events are identical on both paths — same names, same types, same data, same headers. The event catalog is the shared reference; only the transport and the envelope differ. If you run the Community Edition, everything after this paragraph is Kaiten Cloud territory: go to consuming events.
How a delivery happens
- An API write inserts the event into the transactional outbox, in the write's own transaction.
- Change data capture publishes the event to the stream.
- Kaiten Cloud's delivery service forwards it to the webhook provider as a message of its
type. - The provider delivers it to every endpoint subscribed to that type, signs the request, and retries on failure.
Delivery is at least once: an endpoint may receive the same event twice and should deduplicate on the delivery's message id. Signatures, retries, and the delivery history are covered on their own pages below.
The optional headers object carries what is known about the event outside its payload: instance_id, the Instance the event concerns, and traceparent, the trace context of the request that produced it. It is where a usage event names its Instance — payload examples.
What you can subscribe to
55 events across 10 domains — customers, instances, licenses, entitlements, feature flags, components, releases, deployment zones, metadata fields, identity. Every create, update, and delete emits, and so do the commercial moments: a usage threshold crossed, a report refused at a cap, a lifecycle stage change, a release deployed to a zone. Each endpoint subscribes to the event types it cares about, and receives nothing else.
Kaiten gates Kaiten this way. Webhooks are a capability your organization's own Kaiten Cloud License carries, as an entitlement named webhooks in Kaiten's own catalog: a monthly allowance of published events. Every webhooks route checks that the License grants some: where it grants none, the route answers 403, and 503 when the grant cannot be read. The console shows the Webhooks pages only where the route answers. The Community Edition has no service behind those routes, so the pages stay hidden there. Details: managing endpoints; the same entitlement and grant for your own product: gate a feature by License.
In this section
Managing endpoints
Create and delete webhook endpoints in the console, update them over the API, and read their signing secrets.
Event catalog
All 55 events with their names, types, triggers, and payload contracts.
Payload examples
Worked deliveries for the events most integrations start with, on the Kaiten Sushi Shop.
Delivery and retries
The delivery lifecycle, retries, and the delivery history.
Verifying signatures
Prove a delivery came from Kaiten before trusting it.
Where to go next
The receive events page walks through a first delivery on either edition. The concept behind both paths, in one screen: events and webhooks. A ready-made destination: the Slack integration routes these events into a channel.
Overview
Where Kaiten meets the rest of your stack — webhook endpoints on Kaiten Cloud, connectors you activate under your License, the Attio CRM connector, and Slack notifications.
Managing Endpoints
Create and delete webhook endpoints on Kaiten Cloud in the console, update them over the API, and read each endpoint's signing secret — where your License includes webhooks.