GuideApril 7, 20266 min read

How Kite Uses CloudEvents and Rust for Zero-Latency Delivery

A deep dive into the technical architecture behind Kite — why we chose Rust for the relay server, and how the CloudEvents standard makes webhook payloads interoperable across your entire agent stack.

When we set out to build Kite, we had two non-negotiable requirements: sub-10ms relay latency and zero vendor lock-in for event payloads. This guide explains how we achieved both.

Why Rust for the Relay Server

The core relay server is written in Rust. This wasn't a trendy choice — it was a performance requirement.

Webhook relay is fundamentally an I/O-bound, high-concurrency problem. At peak load, a single Kite relay node handles tens of thousands of simultaneous WebSocket connections, each waiting to receive an inbound HTTP event and fan it out in real time.

Rust gives us:

  • •Async I/O with Tokio: Handles massive connection counts with minimal overhead per task.
  • •Zero-cost abstractions: No runtime GC pauses that could spike p99 latency.
  • •Memory safety: No buffer overflows or use-after-free vulnerabilities in the hot path.

The result: our relay server sits at under 2ms median latency for event delivery, with a p99 under 8ms even under heavy load.

The CloudEvents Standard

Every payload that Kite delivers is wrapped in the [CloudEvents](https://cloudevents.io) specification — a CNCF standard for describing event data in a common way.

A raw Stripe payment_intent.succeeded webhook looks like this when it arrives at our relay:

json
{
  "specversion": "1.0",
  "type": "com.stripe.payment_intent.succeeded",
  "source": "https://api.stripe.com",
  "id": "evt_1AbCdEfGhIjKlMnO",
  "time": "2026-04-02T12:34:56Z",
  "datacontenttype": "application/json",
  "data": { ... original stripe payload ... }
}

This wrapping gives you several benefits:

  • •Uniform envelope: Your agent code only needs to understand one event shape, regardless of the source.
  • •Source attribution: The source and type fields tell you exactly where an event came from.
  • •Interoperability: CloudEvents-native tools (Knative, Dapr, OpenClaw) can consume your events directly.

The CLI Binary

The kite CLI is also compiled from Rust. When you run kite listen, it:

1. Authenticates with the relay server using your API key. 2. Opens a persistent WebSocket connection to the relay. 3. Registers your endpoint token as a listener. 4. Forwards received CloudEvents to your local target over HTTP.

The binary is a single static executable with no runtime dependencies — ideal for ephemeral agent environments.

Signature Verification

Kite automatically verifies webhook signatures before relaying. For Stripe, this means checking the Stripe-Signature header against your webhook signing secret. For GitHub, it's the X-Hub-Signature-256 header.

Verified sources include Stripe, GitHub, Slack, Linear, Shopify, Twilio, and PagerDuty. Unverified payloads are still relayed but flagged in the CloudEvent extensions field:

json
{
  "kite-verified": "false",
  "kite-source": "unknown"
}

This lets your agent decide how to trust each event based on its own policy.

What's Next

We're working on a native MCP (Model Context Protocol) sink so language models can subscribe to webhook streams directly. Watch the blog for updates.

← Back to all posts