Managed durable event bus · people and AI agents get the same events
Publishers just emit business events; retention, access control, retries and catch-up are handled for you. The same events reach people over SSE or WebSocket, and AI agents over MCP.
No credit card · three ways in: HTTP, SDK or MCP
Messages stay for the retention window, so they don't vanish when the receiver is offline; replay by cursor within it.
Webhook deliveries retry automatically; the ones that exhaust retries land in a dead-letter queue you can inspect and replay.
SSE resumes from the same cursor on reconnect and fills the gap, within a bounded replay window.
A key is scoped to an action and a topic; room-aware interfaces can narrow it further. Anything beyond returns 403.
Use cases
Five common shapes of event delivery. Each card states its own limits, so you don't have to open the docs to find out.
When orders, tickets or billing state need to reach another system, deliver over Webhook. Failures retry automatically; once retries are exhausted the message lands in a dead-letter queue you can inspect and replay.
Limit: the dead-letter queue only takes Webhook delivery failures — publish and long-poll consumption failures do not go there.
Chat messages, task progress and page state go downstream over SSE or WebSocket. On reconnect you continue from the same cursor — no gap and no duplicates.
Limit: WebSocket is downstream-only, upstream messages are dropped; SSE catch-up is bounded by the retention window and a 5,000-message cap per resume.
Agents subscribe through the official MCP Server — no separate event-to-LLM bridge to build. A new message wakes the agent instead of it polling every few minutes.
Limit: MCP's governance tools need an admin-scoped key, and a key needs an account before it can be minted.
Split one event stream by room. Publishing and SSE / WebSocket subscriptions can both be scoped to a room, so you don't need a topic per group.
Limit: HTTP long-poll has no concept of rooms — it is always the whole topic; presence is aggregated per topic, not per room.
A key is scoped to an action and a topic; interfaces that support rooms can narrow it further. Anything beyond that returns 403, so a leaked key exposes only the one path it opens.
Limit: the dashboard cannot mint room-scoped keys — that goes through the API or an SDK.
Why not just run Kafka
Kafka is underneath. The difference is who carries the six things below.
| Running Kafka yourself | Using MsgMesh | |
|---|---|---|
| Ops | Cluster, monitoring, upgrades, scaling | Managed — no Kafka to babysit |
| Retries & dead-letter | Design your own backoff, persistence, replay | Webhook failures retry automatically; exhausted ones go to a replayable dead-letter queue |
| Resuming after disconnects | Track offsets and handle reconnect catch-up yourself | SSE resumes by cursor inside a bounded replay window |
| Backfilling history | Stand up separate history storage | History query, then continue into the live stream from the same cursor |
| Permissions | Build your own ACL and tenant isolation | Keys scope to an action and a topic; room-aware interfaces narrow further, anything beyond returns 403 |
| AI access | Write your own event-to-LLM bridge | Official MCP Server — agents subscribe directly |
Room scoping applies to publishing, SSE / WebSocket subscriptions, and history queries carrying room; HTTP long-poll operates on the whole topic.
Quickstart
Create a topic, then publish. Run the two separately — creating a topic that already exists returns 409, so putting them in one script stops the second run at the first line.
curl -X POST 'https://msgmesh-api.alderflux.com/v1/topics' \ -H 'Authorization: Bearer YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{"name": "orders"}'
curl -X POST 'https://msgmesh-api.alderflux.com/v1/topics/orders/messages' \ -H 'Authorization: Bearer YOUR_API_KEY' \ -H 'Content-Type: application/json' \ -d '{"orderId": "order_12345", "currency": "TWD", "status": "paid"}'
TypeScript, Python and MCP snippets — and how to fill in the three service URLs — are on Quickstart.
How you receive, and the limits
| Method | Delivery semantics | Where it runs | Notes |
|---|---|---|---|
| Webhook | at-least-once | Needs a publicly reachable URL | Retries automatically; exhausted deliveries go to a replayable dead-letter queue |
| SSE stream() | at-least-once | Browser; the JavaScript SDK does not currently support SSE on Node | Reconnects catch up inside a bounded replay window |
| WebSocket streamWs() | at-least-once | Browser, or Node 22+ | Downstream-only; publish over HTTP |
| HTTP long-poll subscribe() | at-most-once | Node and browser | The offset commits on fetch — a lost response cannot be retrieved |
In production, name your consumer group explicitly. Consumers in the same group share the messages between them; different logical subscribers should each use their own group rather than silently sharing default.
Python's WebSocket support needs an optional dependency; see the docs for runtime details.
Ways in and out
Public beta scope
No exactly-once. SSE, WebSocket and Webhook are at-least-once; HTTP long-poll is at-most-once. Deduplicate by message id.
Deployed in a single Taiwanese facility with single-replica Kafka. A disk or broker failure can permanently lose messages inside the retention window.
Catch-up is bounded by the retention window and 5,000 messages per resume. Beyond that you receive msgmesh-resync and must rebuild state from your own systems — there is no snapshot.
The free plan retains 3 days; the 30-day retention plan is not open during beta. This is not permanent event storage.
Publishing, SSE / WebSocket subscriptions and history queries carrying room. HTTP long-poll works on the whole topic, and presence is aggregated per topic.
The dead-letter queue only handles Webhook delivery failures. Publish failures and long-poll consumption failures do not go there.
If your events directly affect payments, inventory or other core transactions, weigh RF=1 and the single site against your risk requirements first.
The free plan is plenty to get the hang of it · No credit card
Get started free → See pricing first →