Realtime

Turn on live updates so the dashboard reacts the moment something happens — delivery receipts, incoming messages and admin announcements appear as they arrive, without anyone reloading the page.

What realtime does

With realtime configured, the dashboard opens a WebSocket connection and reacts instantly: toasts for sent, delivered and failed messages, incoming SMS and WhatsApp chats, USSD replies, tables that refresh themselves, and admin announcements. Without it, none of that is lost — it is simply not live. Everything still appears when the page is next loaded or refreshed.

Realtime is optional. Leave the credentials blank and Zender works exactly as before, minus the live updates. Nothing else in the product depends on it.

Choosing a provider

Zender speaks the Pusher protocol, which is supported by a hosted service and by several servers you can run yourself. Pick whichever suits you — the protocol is identical, so only the connection details differ.

Provider	Who runs it	Notes
Pusher	Pusher (hosted)	The quickest to set up — sign up, create an app, paste the credentials in. Has a free tier with limits on connections and daily messages.
Sockety	You	Titan Systems' own realtime platform. If you already own Sockety, create an app in its dashboard and use those credentials here.
Soketi	You	Open-source Pusher-compatible server.
Laravel Reverb	You	Also Pusher-compatible, and works with Zender even though Zender is not a Laravel application.

Setting it up

Go to Admin → Overview, press System, and find the Realtime Notifications section.

1. Set Provider to Pusher (Cloud) or Compatible Server (Self-hosted).
2. Fill in App ID, App Key and App Secret from your provider.
3. For Pusher, pick the Cluster your app was created in. Choosing the wrong one is a common cause of a connection that never establishes.
4. For a self-hosted server, enter its full Server URL including the scheme and port, for example https://sockets.example.com:6001.
5. Press Test Connection. This sends a real event through your provider and reports back — do not skip it, see below.
6. Save, then reload the dashboard.

The App Key and App Secret are shown as masked fields and are never sent back to the browser. Once saved, they display a Configured badge and stay blank — leaving them blank when you save keeps the stored value, so you only retype them when you actually want to change them.

What travels over the connection

Each signed-in user gets a private channel that only they can join. The browser asks Zender for permission before subscribing, and Zender only ever grants a user their own channel, so one customer's message notifications can never reach another's browser.

Admin announcements work differently. The realtime message carries only a reference number, never the announcement itself. Each browser then asks Zender for that announcement over its own signed-in session, and anyone who was not a recipient gets nothing back. The text of an announcement is therefore never delivered to people it was not addressed to.

If live updates do not arrive

• Press Test Connection first. If it fails, the problem is the credentials or the server address, not Zender.
• Check the cluster if you are on Pusher. It must match the cluster shown on your app in the Pusher dashboard.
• Check the port and scheme for a self-hosted server. The URL needs the scheme and, unless you are on the default port, the port too.
• A site served over HTTPS cannot open an insecure WebSocket. If your Zender install uses https, your realtime server must use https as well, or the browser will block the connection.
• Check your provider's limits. Hosted plans cap concurrent connections and daily messages; once you are over the cap, events stop being delivered.
• Look in system/storage/temporary/error.log. Failed sends are recorded there with the reason returned by the provider.

Realtime failures never block anything. If the provider is unreachable or misconfigured, messages are still sent, received and recorded exactly as normal — only the live notification is missed.