Receive Events

Managed outbound webhook endpoints are part of Kaiten Cloud, served where your organization's License includes them — where it does not, the console hides the Webhooks pages and the API answers 403. On the Community Edition, use the event-stream path in the other tab.

1. Create an endpoint

In the console, open Integrations → Webhooks and click New Webhook: tick the events to subscribe to — for a first test, Customer created (CUSTOMER_CREATED) is the easiest to trigger — enter your endpoint in Webhook URL, and click Create Webhook.

✕

✕

2. Trigger an event

Create a customer — any create in the model emits its event. In the console: Customers → New Customer, name it Webhook Test Restaurant.

✕

✕

Your endpoint receives the published event contract — the event's name, its versioned type, and the entity as data. A delivery can add an optional headers object of metadata; the payload examples describe it.

{
  "name": "CUSTOMER_CREATED",
  "type": "com.kaiten.customer.v1.created",
  "data": {
    "id": "…",
    "name": "Webhook Test Restaurant",
    "slug": "webhook-test-restaurant"
  }
}

3. Check delivery

Integrations → Webhooks → History lists the most recent delivery attempts with their status — OK, Pending, Sending or Fail (success, pending, sending, fail over the API). Before going to production, verify the signature on every delivery: verifying signatures.

✕

✕

The Community Edition ships no managed webhook delivery. Instead, your self-hosted stack exposes the event stream itself: the same domain events, consumed directly from the message broker your stack runs. The catalog of events is the same; only the transport and envelope differ. The concept page on events covers the two paths side by side; consuming events documents the consumer setup — attaching to the exchange and unwrapping the envelope.