What is Streaming Hub?

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 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 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: 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.

​

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 for how tenant isolation works across Lerian products, and 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 <token>), 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 the hub sees.

The full operation set, request shapes, and error tokens live in the API reference — start from the reference introduction.

​

Next steps

---