A managed event bus for apps, webhooks and AI agents
Send an event to MsgMesh and it is retained, then delivered over SSE, WebSocket, Webhook or MCP. You do not have to rebuild reconnects, retries and permissions in every service.
Free with no credit card · publish your first event in about five minutes
See it working first
All three demos use the live public service, not a recording. Start with the event wall, then try room isolation in chat and support flows.
Automated events, other visitors and your own message share one stream. Switch between SSE and WebSocket without signing up.
Use cases
Five common delivery patterns, each with its best use and limits stated up front so you can decide quickly.
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.
Explore Webhook retries and DLQ →Chat messages, task progress and page state go downstream over SSE or WebSocket. After a disconnect, catch-up resumes from the cursor; the official SDK deduplicates by partition cursor.
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.
Compare SSE and WebSocket →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.
Explore AI agent event subscriptions →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.
How it works
MsgMesh sits between producers and receivers: it retains each event, then delivers it using the protocol and delivery behavior each receiver needs.
Messages stay for the retention window. Late receivers can replay them by cursor.
Temporary Webhook failures retry automatically. Exhausted deliveries land in a dead-letter queue you can inspect and replay.
SSE resumes from the same cursor and fills the gap within a bounded replay window.
Scope keys to actions and topics. Room-aware interfaces can narrow them further; anything beyond returns 403.
Why not just run Kafka
With Kafka, your team owns the cluster, offsets, reconnects, retries, and access control. MsgMesh packages those concerns behind HTTP, SSE, WebSocket, Webhook, and MCP.
| 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"}'
Complete TypeScript, JavaScript, Python and MCP snippets — plus the three service URL settings — 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
Plans
Both plans include realtime delivery, Webhook retries and MCP. Paid adds throughput, topics, retention and included operations.
1 million operations per period, 5 topics and 3-day retention. For integration trials and small projects.
Create a free account6 million operations per period, 1,000 topics, 30-day retention and higher throughput. No SLA during public beta.
See full pricing →Overage is off by default, so usage does not create a surprise charge. Subscriptions can be cancelled; Polar helps process payments, taxes and refunds. See Pricing, the Terms and the Refund Policy for details.
Public beta scope
No exactly-once. SSE, WebSocket and Webhook are at-least-once; HTTP long-poll is at-most-once. The official SDKs deduplicate by partition cursor.
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.
Free retains messages for 3 days; Paid retains them for 30 days. Neither is 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.
Free is enough to validate an integration · No credit card
Create a free account → See pricing first →