Connect the systems your people already use

Connect an existing Zello channel today, or put live voice inside the dispatch board, WMS or job app your people already stare at. Here is what ships now and what still needs to be built.

See the Zello connector What the API can do

Partly shipping. The Zello Channel Connector and the API are real and running. A published SDK and webhooks are not built. The split matters if you are planning work, so it is marked throughout.

Zello Channel Connector — shipping now

Link one encrypted push.tt channel to one Zello channel and carry live voice in both directions. It is the practical path when the two teams need to talk now and the migration can happen later.

One channel at a time. Connect Dispatch without touching every other conversation on either service
Opus voice crosses without a decode-and-re-encode cycle. The connector relays the same 16 kHz audio packets in both directions
The push.tt server still cannot listen. A keyed connector on your Linux host decrypts locally before audio enters Zello
The boundary is visible. Every push.tt member sees that connected audio leaves end-to-end encryption and is governed by Zello
See exactly what ships, what does not cross and what the connector requires.

Voice only. Direct calls, text, locations, images and emergency alerts do not cross. The connector needs an always-on Linux host, a dedicated Zello Work user and one standard push.tt device licence.

The API — built and running

A plain HTTPS + WebSocket API with bearer tokens. Not a side door: the management console and the Android client are written against exactly these endpoints, which is the only real guarantee that an API stays working.

Users and organisations. Provision accounts, set roles, revoke a device, read presence
Channels. Create, add and remove members, manage moderators
Messages and history. Send text, alerts, images and locations; read back a channel log
Live events over one WebSocket. Presence, channel occupancy, floor control, emergencies and voice frames all share the socket the clients use
Store and licensing. Buy seats and eSIMs, assign them, read the wallet ledger

One consequence to design around rather than discover: the server cannot read encrypted content. An integration that needs message bodies has to hold a key and decrypt client-side, or run against a channel you have deliberately left unencrypted. There is no server-side API that returns plaintext for an E2EE channel, and there will not be one.

An SDK — not built

Embedding PTT in someone else's app is a genuinely different product from shipping ours, and we would rather say so than list it as available.

What exists today is a working Android client whose voice pipeline is a separate module — capture, codec negotiation, framing, floor control and crypto are already not entangled with the UI
An Android SDK is therefore extraction work rather than new invention. That is a real difference in cost, and the honest word is still "unbuilt"
The native iOS client is source-complete and simulator-tested, but signing, the PushToTalk entitlement and physical-device validation remain release gates, so an iOS SDK still sits behind that
React Native was explicitly rejected for our own client — a 20 ms audio loop across a bridge is the wrong architecture, and we are not going to recommend for your app what we refused for ours

Webhooks — not built

The most common ask we expect, and currently the answer is polling the API or holding the WebSocket open. Worth naming what a real implementation has to get right, because it is why this is not a weekend feature:

Signed payloads with a timestamp tolerance, so a captured delivery cannot be replayed at you forever
At-least-once delivery with an event id, so your endpoint can be idempotent — because ours will retry
Retry with backoff and a dead-letter path, rather than dropping a delivery when your server has a bad minute
And the same content limit as everywhere else: a webhook can tell you that a voice message arrived on a channel, never what was said in it

What we can help with now

Small team, so this is a real conversation rather than a support tier with a name.

Working through whether your integration is possible under end-to-end encryption — some are not, and finding out early is cheap
API access and a test organisation so you can build against something real
Shaping the endpoints you need. The protocol is a shared package the clients build from, so adding to it is normal work rather than a favour
White label if what you actually want is your own branded app, and industry modules if it is your industry's screens on top of ours

Describe the integration

Which system, which direction the data flows, and whether it needs message content or only the fact of a message. That last one decides more than anything else — and it is the question most integration conversations skip until it is expensive.

Talk to us