Build with RTLayer

RTLayer sits between your backend and your users’ apps. Your server sends a message to the HTTP API; RTLayer fans it out to every client connected to the same service over a websocket. Clients never publish: anything they need to send goes through your own backend, which keeps you in control of what is broadcast.

• HTTP API: https://api.rtlayer.com. Publish messages and create services. Authenticated with an API key.
• Websocket: wss://ws.rtlayer.com/<orgId>/<serviceId>/. Clients connect, join channels and receive messages.
• Dashboard: rtlayer.com/dashboard. Create services, manage API keys and teammates, try messages in the Playground and watch live analytics.

1. Sign in. The first visit to Home creates an organization, a service and an API key for you.
2. Open your service on the Dashboard and go to API Keys. Copy the Organization ID, the Service ID and an API key.
3. Connect a client and listen on a channel (step 3 below).
4. Publish to that channel from your server (step 4 below).
5. Watch it arrive. The service’s Playground tab can also send and receive test messages, with timings.

A successful call returns 200 with {"status":"ok"}. The response is the same whether the message reached clients, was stored for later, or found nobody listening; it is not a delivery receipt.

RTLayer(orgId, serviceId, token?, retryInterval?) returns a client that connects at once and reconnects every retryInterval ms (default 5000) when the connection drops, re-joining your channels. It needs a global WebSocket: browsers, React Native and Node 22+ have one.

The SDK is a thin layer over a small JSON protocol, so any language with a websocket client works.

By default anyone who knows your org and service IDs can connect and join any channel. That’s fine for public data. For anything private, turn on authentication: clients must then present a JWT that your server signs with the service’s secret.

1. In the dashboard, open the service’s Settings tab, switch on Require authentication and set a long random secret (owners and admins only).
2. On your server, after you have authenticated the user, sign a token with that secret (HS256) carrying the claims below.
3. Give the token to the client, which connects with it.

• A missing, invalid or expired token, or IDs that don’t match the URL, fail the websocket handshake (HTTP 401). Browsers report this only as a failed connection.
• A join the token doesn’t allow gets an error frame; the connection stays open.
• Patterns are matched against the whole channel name. Stick to letters, digits, -, _ and : in channel names: other symbols such as . have special meaning in patterns.
• Turning authentication on or changing the secret can take up to 10 minutes to apply to new connections.
• The JavaScript client is reused per org and service, so a fresh token takes effect after a page reload.

• Live delivery: a message goes to every client subscribed to its channel at that moment (all clients of the service for a broadcast). Messages you publish one after another arrive in that order; requests sent in parallel can arrive in any order.
• At most once: there are no acknowledgements or retries. Clients that are offline, reconnecting or too slow to keep up miss messages. Treat RTLayer as the fast path, and let clients re-sync from your API after a reconnect when every message matters.
• No history: messages are not stored, except as described for TTL below.

With ttl, a message published to a channel nobody is currently subscribed to is kept for up to ttl seconds. The first client to join that channel within that time receives it. Details worth knowing:

• If anyone is subscribed when you publish, the message is delivered live and ttl has no effect.
• A stored message is handed out once: to the client(s) that join first, not to everyone who joins later.
• Identical messages stored for the same channel are kept once. Add an ID or timestamp if repeats matter.
• Stored messages are delivered in expiry order and are kept for at most about 24 hours, whatever the ttl.

An org key belongs to an organization rather than a single service. Use it on servers that manage many services. Owners and admins create and disable org keys on the organization page; every member can see them.

• Every new service comes with one service key. Create more to rotate keys without downtime: add the new key to your servers, then disable the old one.
• Disabling is permanent; a disabled key can’t be re-enabled. It stops working within about a minute.
• A disabled key and a key that never existed both get 401 Invalid API Key.

Errors come back as JSON: {"status":"error","message":"<text>","code":<status>}. Validation errors are 400 with a list instead: {"status":"error","message":[{"field":"message","message":"Required"}]}.

• /llms.txt: a short index of these docs in the llms.txt format.
• /llms-full.txt: this whole page as one Markdown file. The Copy as Markdown button at the top copies the same text.

1. Ask the user for their org ID, service ID and a service API key (dashboard → service → API Keys). Never put the API key in client code; read it from an environment variable such as RTLAYER_API_KEY.
2. Server side, publish with POST https://api.rtlayer.com/message, header x-api-key, JSON body {"channel": "...", "message": ...}. Check for {"status":"ok"}.
3. Client side, use rtlayer-client: RTLayer(orgId, serviceId).on(channel, handler), and JSON.parse the message when you published an object.
4. If the data is private, enable authentication and sign tokens on the server with orgId, serviceId, uid and room.allowed.
5. Verify end to end: subscribe, publish, and confirm the handler fires (or use the service’s Playground tab).