What is Metered Realtime Messaging?
Metered Realtime Messaging is a bi-directional WebSocket service that lets your clients exchange messages over channels (publish/subscribe) or directly (peer-to-peer by ID), with built-in presence and JWT-based authorization.
It is the same product, regardless of whether you're using it for WebRTC signalling, AI agent coordination, IoT telemetry, or live chat. The wire protocol is intentionally general-purpose — what changes between use cases is how you model channels and messages, not the API surface.
Core capabilities
| Capability | What it does |
|---|---|
| WebSocket connections | Long-lived, low-latency, bi-directional. One per peer. |
| Channels | Pub/sub fan-out. Subscribe to a channel; publishers reach all subscribers. Wildcards (app_xyz/*) routed at the server. |
| Direct messages | Peer-to-peer send by peerId. No channel required. Used for WebRTC SDP/ICE, agent-to-agent tool calls, command-and-control. |
| Presence | Automatic peer-joined / peer-left events on subscribe/disconnect. Optional peerMetadata (userId, profile pic, anything you want) included. |
| Two-key auth model | pk_live_… for browser-shipped credentials (Bearer at connect time), sk_live_… for server-side JWT minting (HS256 with kid header). |
| REST control plane | Mint tokens, list peers in a channel, server-side publish, forcibly disconnect a peer, query usage. |
| TURN integration | Mint Metered TURN credentials in your backend, embed them in the JWT's metadata.iceServers field — your peer receives them in the connect-time welcome message. |
| Dual-axis billing | Plans are sized by both concurrent connections AND messages per period. Soft drops on over-quota when overages are off; bill-at-rate when overages are on. |
Why a general-purpose protocol
Real-time apps tend to look similar from the wire's perspective:
- A user opens a tab → that's a connection
- Multiple users gather around a topic → that's a channel
- A user signs in → their peerId identifies them
- The app needs to know who else is around → that's presence
- One user sends a thing to another specific user → that's a direct message
- Some users have privileged metadata (userId, role) → that's peerMetadata
A WebRTC signalling server, an AI agent bus, a chat backend, a fleet-telemetry hub, and a Figma-style cursor server all reduce to the same five primitives. We didn't want you running five different services to get them.
How it relates to other Metered products
- TURN Server is the media-relay layer for WebRTC. Realtime Messaging is the signalling layer for WebRTC. They are designed to be used together — see the WebRTC Signalling guide for the pattern where your backend mints both in one step and ships them to the browser via a single JWT.
- Global Cloud SFU is a Selective Forwarding Unit for media streams (audio/video routing). It uses its own signalling channel. Realtime Messaging is the right pick when you want to build a signalling protocol of your own (e.g. for an SDK or a custom WebRTC topology).
- Video SDK is a high-level video-call library that hides all of this behind a
joinMeeting()call. Use Realtime Messaging directly when you want lower-level control or are building infrastructure that isn't a video call.
What's next
- Use cases — see how each fit looks in practice
- Quickstart — connect, subscribe, and publish in under 30 lines
- Protocol Reference — the wire format in full