Concept

Sinks

Where Kite delivers events — stdout, HTTP proxy, Unix socket, exec, and agent sinks.

A sink is where Kite delivers events after receiving them from a source. Kite supports several output modes.

stdout (stream)

The default sink. Events are printed to stdout as human-readable summaries or JSON:

bash

kite stream             # summary mode
kite stream --json      # full CloudEvent JSON, one per line
kite stream --compact   # minimal one-liners

Ideal for human-readable monitoring, log pipelines (kite stream --json | jq ...), and quick debugging.

HTTP proxy

Forward events to a local HTTP server. Kite sends a POST request whose JSON body is the CloudEvent data payload, plus CloudEvent and Kite metadata headers:

bash

kite proxy --target http://localhost:3000/webhooks

Headers forwarded on each request:

x-kite-source — source slug
x-kite-event-id — Kite delivery ID
x-kite-event-type — CloudEvent type
x-kite-team-id — your team ID
ce-id, ce-source, ce-type, ce-specversion, ce-time — CloudEvent context attributes

Unix socket (listen)

Kite can create a Unix domain socket and write CloudEvent JSON to it. Useful for low-latency IPC with a local agent process:

bash

kite listen --socket /tmp/kite.sock

Exec

Run a subprocess for each event, passing the CloudEvent JSON on stdin:

bash

kite stream --exec "python3 handle_event.py"

The subprocess receives one event per invocation on stdin and should exit 0 to acknowledge.

Agent sinks (MCP)

For agentic orchestration platforms, install the Kite skill and use a manifest sink:

bash

kite skill install kite
kite run --manifest kite.json

Use mcp_server for MCP-aware local agents, or an HTTP sink for hosted agent runtimes. See Agent Integration for setup and Security for credential and signature guidance.

Local queue

Events that fail delivery (non-2xx/non-3xx from HTTP proxy, exec non-zero exit) are stored in the local SQLite queue. Replay them with:

bash

kite queue replay --target http://localhost:3000/webhooks