Destinations

Destinations are Causet’s outbound delivery platform. After the runtime commits an intent to the ledger, matched events are delivered to external systems (Kafka, HTTP webhooks) or to connected realtime clients (WebSocket / SSE) through a durable job engine in causet-realtime.

Destinations replace the older Settings → Webhooks configuration. Configure outbound HTTP, Kafka, and websocket delivery under Settings → Destinations. Inbound provider webhooks (provider → your app → submitIntent) are a separate pattern — see Use Webhooks to Update Existing Flows.

Why destinations exist

Runtime commit must stay local to Postgres (ledger + snapshots + cursor). Calling customer brokers or HTTP endpoints inside that transaction would:

Hold entity locks across unpredictable external latency
Couple commit success to customer infrastructure availability
Force the runtime to hold customer credentials

So Causet commits first, then delivers asynchronously.

Three planes

Plane	Service	Owns
Runtime	`causet-runtime-service`	Ledger commit + publish of a versioned committed-event envelope to internal Kafka. Never opens customer connections or stores customer broker/webhook secrets.
Control plane	Causet Cloud (SaaS + UI)	Destination resources, subscriptions, config versions, secret references, test connection, Delivery Log, pause/resume, credential rotation.
Data plane	`causet-realtime`	Match subscriptions → persist delivery jobs → run adapters (Kafka / webhook / websocket) with retries, leases, and Delivery Log.

Runtime ledger commit
  → internal Kafka (causet.committed-events.v1)
    → causet-realtime outbound engine
      → match subscriptions → event_delivery_jobs
      → adapters
           ├─ kafka   → your brokers / topic
           ├─ webhook → your HTTPS endpoint
           └─ websocket → connected SSE / WebSocket clients

Adapter types (today)

Type	Use when
Kafka	You want durable export into a customer-managed cluster (Confluent, MSK, self-hosted).
Webhook	You want Causet to POST committed events to your HTTPS endpoint (replaces legacy managed webhooks).
Websocket	You want interactive client fan-out via the same job engine (SDK `connectStream` / SSE).

Additional adapters (EventBridge, SQS, Pub/Sub, …) are on the roadmap; they plug into the same destination registry without runtime changes.

Destinations vs live streams

	Destinations (Kafka / webhook)	Live SSE / WebSocket
Purpose	Durable export / HTTP callbacks	Interactive UI updates
Durability	Jobs + retries + Delivery Log	Best-effort to connected clients
Config	Settings → Destinations	SDK `connectStream` / WS protocol
Dedupe	Required (`causet-event-id` / body `id`)	Client-side optional

When outbound is enabled, websocket destinations feed the local hub so clients are not double-notified from a separate patches consumer.

Quick start

Open Settings → Destinations in Causet Cloud (or the local control plane).
Create a Kafka or Webhook destination for your fork / environment.
Add a subscription with event-type patterns (e.g. order.* or *).
Use Test connection, then watch the Delivery Log.
In your consumer / webhook handler, dedupe on body id (Kafka header causet-event-id, webhook X-Causet-Event-Id).

See:

Permissions & secrets

Cloud permission: platform:write (or destinations:* scopes)
Secrets are encrypted with CAUSET_SECRETS_MASTER_KEY (shared by SaaS and realtime)
APIs never return stored secret values after create (passwordConfigured: true)

SSE / WebSocket — live client subscriptions
Use Webhooks to Update Existing Flows — inbound + outbound bridge patterns
Workflows — event-driven multi-step processes that often fan out through destinations

Examples Kafka