Arc
Protocol

Errors and close codes

What Arc sends when something is wrong, and what clients do about it.

Errors arrive as a pusher:error frame. Codes are grouped into bands, and SDKs act on the band rather than the exact number.

BandWhat the client does
4000–4099Do not reconnect
4100–4199Reconnect after a backoff
4200–4299Reconnect immediately
4300–4399Close, do not retry

Codes Arc sends

CodeClosesWhen
4001YesUnknown app key, or the app was deleted
4003YesApp disabled
4004YesApp is over its connection limit
4007YesProtocol version other than 7
4008YesNo protocol version supplied
4009YesUser sign-in failed
4100YesNode over capacity, or still starting up
4101YesNode shutting down
4102YesThe client is not reading fast enough
4201YesNo pong after a server ping
4300YesConnections terminated by your backend
4301NoClient event over the rate limit
nullNoMalformed frame, unknown event, rejected client event

A code of null means the frame was wrong but the connection is fine: the SDK surfaces it to your error handler and carries on.

Subscription errors

Failing to join a channel is reported on the channel, not the connection:

{
  "event": "pusher:subscription_error",
  "channel": "private-orders",
  "data": "{\"type\":\"AuthError\",\"error\":\"Invalid signature: ...\",\"status\":401}"
}
StatusMeaning
401The signature did not verify, or was missing or malformed
403The app forbids it: a full presence channel, or a user channel that is not yours
400Invalid channel name, or channel_data without a user_id

Slow clients

Arc watches how far behind each connection is. If a client stops reading and its queue passes 5,000 messages, Arc closes it with 4102 rather than letting one slow consumer grow until it takes the node's memory with it. The SDK reconnects after a backoff and starts clean.

On this page