Event Catalog

Kaiten Cloud

Kaiten emits 55 domain events across 10 domains. This page lists every one of them. The events exist on every edition — the badge marks the delivery path this section documents: on Kaiten Cloud they reach your webhook endpoints; on a self-hosted stack you consume them from RabbitMQ. Same names, same types, same data on both paths.

The contract

Every event is a published contract of three fields, and a delivery can carry a fourth, optional one:

headers is present when the event has metadata to carry, and a consumer should ignore the keys it does not read. instance_id is set on every event of the Instances domain. It is where a usage event names its Instance: the usage payloads identify the entitlement — EntitlementUsage the License too — and only the period rollover and the value read carry an instance_id of their own.

The Payload column below names the schema data carries. Entity snapshots (Customer, Instance, License, …) are the same objects the REST API returns, with camelCase fields; change records (InstanceStatusChanged, InstanceEntitlementCapExceeded, …) are event-specific and use snake_case fields. Every contract — field by field, with its schema — is in the generated API reference's Webhooks group, one page per event: that is the exhaustive machine view of this catalog.

Customers

Instances

Licenses

A License family is the product its versions belong to. It has no write operation of its own — its first version opens it and its last one takes it away — so its three events are recorded by the version writes that change it, and they are listed here, under Licenses: the catalog keeps 10 domains. LicenseFamilyView carries the family and, in currentVersion, the version it serves — absent while the family has nothing published.

Entitlements

Feature flags

Components

Releases

Deployment zones

Metadata fields

Identity

Subscribing

On Kaiten Cloud, a webhook endpoint subscribes to events by type — the second column above — and receives every event whose type is on its list, and nothing else. POST /webhooks takes those types in eventTypes and refuses an event name with 400; there is no "all events" subscription. Create the endpoint under Integrations → Webhooks or over the API; managing endpoints has both. Delivery is at least once, so a handler should be idempotent; retries and the delivery history are on delivery and retries.

The console's New Webhook dialog offers 53 of the 55 events. It leaves out ENTITLEMENT_VALUE_GET and FEATURE_FLAG_EVALUATED, which fire on every entitlement read and every flag evaluation: subscribe an endpoint to either over the API, by its type.

On a self-hosted stack, the same names arrive as the outbox row's event_name, and each message's type is the event's, which your consumer filters on — consuming events. Inside the API, one delivery of the same stream is fanned out to several in-process consumers — the audit trail, and a CRM connector for the organizations that activated one — each keeping its own record of what it has processed, so a failure in one is retried for that one alone. Your consumer is not part of that fan-out: it binds its own queue to the exchange and keeps its own record.

Where to go next

• Payload examples — worked deliveries on the Kaiten Sushi Shop
• Generated API reference, Webhooks group — one page per event, with the full data schema
• Events and webhooks — the concept in one screen; audit trail — the same stream, kept