Skip to main content
Version: MVP

Channel adapter contract

3 min readReferenceUpdated 2026-05-19

What you'll find here

The boundary contract for external operator ingress through always-on gateway channels — adapter identity, capabilities, inbound/outbound shapes, receipts, and trust boundaries.

Descriptive, not authorizing.

The contract validates and inspects channel adapter identity, payload shape, capabilities, receipts, and trust boundaries before a specific adapter is wired into the gateway.

Identity

Stable adapter id

Channel kind

messaging · webhook · scheduler · voice · custom.

Human-readable name

Adapter version

Optional external service name

Identity is not authorization. It only identifies the adapter implementation and channel family.

Capabilities

Each capability declares:

Field
Values
Notes
Direction
inbound / outbound / bidirectional
How traffic flows.
Description
prose
What the capability does.
Grant required?
bool
Most capabilities require a grant.
Receipt required?
bool
Most capabilities require a receipt.

No ambient authority.

Channel capabilities are still governed by policy envelopes and explicit grants. Adapters do not receive ambient authority from being installed or configured.

Inbound events

Required fields: event_id · channel · received_at · sender.

Adapters may include additional normalized fields such as text, thread_id, or channel-specific metadata. Sensitive payload fields should be listed in redacted_fields.

Outbound responses

Required fields: status · summary.

Adapters may include delivery metadata, response ids, text bodies, receipt ids, or channel-specific fields. Provider details remain nested under metadata rather than expanding the core contract into a channel matrix.

Receipts

Channel adapter contracts require craik.capability_receipt receipts. Receipt capabilities must be declared by the adapter contract, so inbound and outbound channel activity stays auditable under the same policy model as runner and tool actions.

Local store

The v0.8.0 gateway artifacts are durable store contracts. The local store exposes typed helpers for channel adapter contracts, identity pairings, allowlists, channel policy envelopes, gateway schedules, scheduled automations, and gateway receipts so an accepted ingress or scheduling decision can be inspected after restart.

Trust boundaries

Policy envelopes required

Allowlist enforcement

Inbound identity handling

Secrets outside contract & config

Future channel adapters can add delivery-specific behavior, but they must keep authorization, identity pairing, redaction, and receipt emission visible at this contract boundary.

What's next