> ## 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 events out to 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. It 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 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**, and events from every product and tenant ride the same topics. To consume it directly, you must run your own Kafka consumer. That consumer tracks offsets, filters event types, deduplicates, retries failed deliveries, and signs outbound requests. Streaming Hub does that work once, as a managed edge. It **consumes** the internal stream and never produces onto it. It 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/platform/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 a verified outbound credential or an AWS delegated grant. | | `rabbitmq` | Push | A RabbitMQ exchange and routing key. | | `eventbridge` | Push | An Amazon EventBridge event bus, reached through a verified outbound credential or 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. A webhook subscription becomes deliverable after one signed probe confirms your endpoint answers. RabbitMQ subscriptions require a broker credential that the hub probes before activation. SQS and EventBridge can activate with an outbound credential that the hub probes, or with a delegated AWS grant that stores no credential. See [Managing subscriptions](/en/platform/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 one configured control-plane tenant 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 and runs one application Kafka consumer per ingest-capable replica with deployment-level broker credentials. Tenant Manager supplies the active-tenant roster used to authorize the control plane. A Redis lifecycle listener and a periodic refresh keep that roster current. The roster does not create one consumer per tenant or act as an ingest drop gate. Secrets Manager remains the credential source for authenticated producer-manifest discovery, not for the Kafka connection. Subscriptions, events, and cursors remain isolated by tenant id. The BYOC path carries none of that machinery. See the platform-wide [multi-tenancy model](/en/platform/multi-tenancy) for how tenant isolation works across Lerian products, and [Operating Streaming Hub](/en/platform/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 `). The tenant always comes 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.