> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # What is Streaming Hub? > Streaming Hub is Lerian's managed delivery edge — it consumes the platform's internal event stream and fans each event out to your external webhook, queue, and pull consumers. **Streaming Hub** is Lerian's event-delivery service. It sits at the edge between the platform's internal event stream and the systems you run outside it, and delivers each event you care about to a destination you own — a webhook, a cloud queue, or a cursor you pull. Lerian products publish domain events — past-tense business facts such as an account being created or a transaction being posted — onto a shared streaming backbone. Streaming Hub subscribes to that backbone on your behalf, matches the events against the subscriptions you register, and delivers them. You describe *which events go where*; the hub owns the consume, match, and deliver loop. Streaming Hub is closed source and available to licensed Lerian customers; its repository is maintained internally. ## Streaming Hub in the Lerian platform *** The platform's event backbone is a shared, [CloudEvents-based stream](/en/reference/events/overview) carried on Kafka/Redpanda and produced through Lerian's `lib-streaming` library. Delivery on that stream is **at-least-once**, events from every product and tenant ride the same topics, and consuming it directly means running your own Kafka consumer: tracking offsets, filtering event types, deduplicating, retrying failed deliveries, and signing outbound requests. Streaming Hub does that work once, as a managed edge. It **consumes** the internal stream — it never produces onto it — and turns a raw event feed into per-destination delivery you configure through a single API. You register a subscription, the hub tracks the stream, and matched events arrive at your endpoint already signed and correlated. Because the hub is the delivery edge, the guarantees you build against are the hub's delivery contract, not the raw stream: your webhook endpoint verifies a signature, deduplicates on a stable event id, and returns quickly. See [How Streaming Hub works](/en/streaming-hub/how-streaming-hub-works) for the full path an event takes. ## Sink kinds *** A subscription delivers to exactly one destination, called a **sink**. Streaming Hub supports five sink kinds: | Sink kind | Delivery | Destination | | ------------- | -------- | ------------------------------------------------------------------------------------------------------------------------- | | `webhook` | Push | An `https://` endpoint you own. Each request is HMAC-signed and carries CloudEvents correlation headers. | | `pull` | Pull | A server-side cursor. Your consumer reads a page of events with `GET /v1/events`; the read doubles as the acknowledgment. | | `sqs` | Push | An Amazon SQS queue, reached through an AWS delegated grant. | | `rabbitmq` | Push | A RabbitMQ exchange and routing key. | | `eventbridge` | Push | An Amazon EventBridge event bus, reached through an AWS delegated grant. | Push sinks (`webhook`, `sqs`, `rabbitmq`, `eventbridge`) deliver events to you as they match. The `pull` sink inverts that: the hub holds events on a cursor and your consumer fetches them on its own schedule. Webhook subscriptions are ready to receive as soon as you create them. Queue subscriptions (`sqs`, `rabbitmq`, `eventbridge`) deliver nothing until you supply and verify their outbound credential — see [Managing subscriptions](/en/streaming-hub/managing-subscriptions). ## Deployment model *** Streaming Hub runs **BYOC** by default: you deploy it into your own infrastructure as a single-tenant service, with a static tenant roster and no dependency on Lerian-hosted tenant management. This is the shape most clients run. A **SaaS multi-tenant** mode sits behind a configuration flag. When enabled, the hub serves many tenants over the shared bus, admits tenants from a cache-backed roster fed by Lerian's tenant manager, and isolates every tenant's subscriptions, events, and cursors by tenant id. The BYOC path carries none of that machinery. See the platform-wide [multi-tenancy model](/en/multi-tenancy) for how tenant isolation works across Lerian products, and [Operating Streaming Hub](/en/streaming-hub/operating-streaming-hub) for the deployment details. ## The control-plane API *** You manage subscriptions through the `/v1` control-plane API. Every route is authenticated with a plugin-auth JWT (`Authorization: Bearer `), and the tenant is always taken from the validated token claims — never from a request body, path, or query. Through it you: * create, list, read, and delete subscriptions; * verify a destination (`ping` / `verify`) and supply queue credentials; * rotate a webhook signing secret; * read a subscription's delivery health; * pull events (`GET /v1/events`) for `pull` sinks; * browse the event [catalog](/en/reference/events/overview) the hub sees. The full operation set, request shapes, and error tokens live in the API reference — start from the [reference introduction](/en/reference/introduction). ## Next steps *** The path an event takes: ingest, match, dispatch, retry, and auto-disable. Create webhook and queue subscriptions, wire AWS grants, and rotate secrets. Verify webhook signatures, deduplicate deliveries, and pull events. The shared CloudEvents contract every Lerian event follows.