WebSockets
What is WebSockets?
WebSockets is a protocol that keeps one long-lived, full-duplex connection open between a client and a server, so both sides can push messages at any time without opening a new HTTP request. After a short HTTP upgrade handshake, the connection persists and either party sends data the moment it exists — which is why WebSockets is the standard transport for live chat, real-time dashboards, and streaming voice and message events.
More detail
A WebSocket session starts as an ordinary HTTP request that negotiates an upgrade, and once the handshake succeeds the same TCP connection carries framed messages in both directions. That design replaces two older workarounds: polling, where the client asks 'anything new?' on a timer, and long-polling, where the server holds a request open until it has something to return. Because the channel stays open, latency drops from polling-interval seconds to network round-trip milliseconds.
In a communications platform, WebSockets carries the events a webhook cannot reach or a browser cannot receive: a live inbox pushing inbound messages to an agent's screen, a browser-call client negotiating audio in real time, or a voice agent streaming call audio to and from a speech model. For server-to-server delivery of the same events — delivery receipts, inbound messages, call lifecycle — platforms still use signed HTTP callbacks, and WebSockets and webhooks usually coexist in one integration.
A WebSocket is transport, not media: it moves bytes. Voice and video over a WebSocket connection ride as data streams on top of it, while native browser-to-browser calling typically uses WebRTC for the media plane and a WebSocket-style channel only for signaling. Knowing which layer WebSockets sits on keeps a real-time architecture honest about what still needs a media server.
Frequently asked
- How are WebSockets different from regular HTTP?
- HTTP is request–response: the client opens a connection, asks, receives, and the exchange ends, so a server cannot reach the client until it asks again. WebSockets upgrades one HTTP connection into a persistent channel where both sides push messages whenever they have data, which removes the polling loop entirely.
- When should I use WebSockets instead of webhooks?
- WebSockets fit when the receiver is a client that can hold a connection — a browser inbox, a mobile app, a desktop agent — and needs events the moment they happen. Webhooks fit server-to-server delivery, where a signed HTTP POST to a stable endpoint is easier to secure and retry. Many integrations use both: webhooks between back ends, WebSockets to the user interface.
- Do I still need polling if I use WebSockets?
- No. Once the upgrade handshake completes, either side pushes data as it arrives, so the client stops asking the server for updates on a timer. A keep-alive ping keeps the channel from being closed by idle timeouts, but that is a heartbeat, not polling for content.
See also
Build it on Orbit
Voice, messaging, email, video, and AI agents on one platform and one pay-as-you-go bill. Start free — no credit card required.