Live voice, inside the system your people already stare at

Most of a shift is spent in one screen — a dispatch board, a WMS, a job app. The best place for push-to-talk is inside it, not in a separate app somebody has to remember to open. Here is what exists to build that with, and what does not exist yet.

Tell us what you are building What the API can do

Partly shipping. The API is real and running — the console and both clients are built on it, so there is no separate, less-tested integration path. A published SDK and webhooks are not built. The split matters if you are planning work, so it is marked throughout.

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"
iOS is a partial reference port and resumes after Android ships, so an iOS SDK 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