Pusher protocol

The Pusher protocol is an open application-layer protocol that runs over a WebSocket connection. It defines channel subscription frames, named events, member presence on shared channels, and a signed auth handshake for restricted channels. The protocol is implemented by multiple independent servers and a broad ecosystem of client SDKs.

Why it matters

The Pusher protocol is one of the cleanest channel-based real-time protocols in production use. It has well-defined semantics for public channels, private channels, and presence channels, with SDKs in every language a working developer is likely to ship in. Because the protocol is the contract (not the host, not the vendor), applications written against it are portable across any server that implements it.

This portability is the wedge for migrations. A Laravel app using laravel-echo and pusher-js, or a Rails app using pusher-http-ruby, or a Python app using pusher-http-python, all connect to any Pusher-protocol-compatible server by changing host and credentials. The application code that calls channel.bind(event, handler) does not change.

How it works

The protocol layers over a standard wss:// connection. After the WebSocket handshake completes, a few frame shapes drive the entire flow.

  • pusher:subscribe to join a channel. Public channels accept the frame directly. Private and presence channels require an auth token returned by the application's channel auth callback.
  • pusher:unsubscribe to leave.
  • Named application events on subscribed channels, delivered as JSON frames with event, channel, and data fields.
  • pusher:ping and pusher:pong for liveness.

A minimal subscribe frame looks like:

{ "event": "pusher:subscribe", "data": { "channel": "live-cursors-doc-42" } }

A delivered event frame looks like:

{
    "event": "cursor.moved",
    "channel": "live-cursors-doc-42",
    "data": "{\"x\":120,\"y\":340}"
}

The protocol also defines pusher_internal:* events for system signals (member join, member leave, subscription confirmed) which the SDKs surface as ergonomic callbacks.

Related terms

  • WebSocket is the transport the protocol runs on.
  • Channel auth is the handshake for joining restricted channels.
  • Broadcast is the unit of work the protocol delivers as an event frame.

See also

Is the Pusher protocol open?
Yes. The wire protocol is publicly documented and has multiple compatible server implementations. Client SDKs in JavaScript, PHP, Ruby, Python, Go, Swift, and others speak it natively.
Is the Pusher protocol the same as raw WebSockets?
No. WebSocket is the transport. The Pusher protocol is the application layer on top: channel subscribe and unsubscribe frames, named events, member presence, and a signed auth handshake for private and presence channels.
Can I use the Pusher protocol with a non-Pusher service?
Yes. Any server that implements the protocol is a valid target for Pusher-protocol clients. The client SDKs care about the protocol on the wire, not the host on the other end.