Limits

What the gateway enforces

These are the numbers the gateway actually checks, not aspirations. When one trips you get an error frame or a 429, never a silent drop.

Per connection

Limit	Value	On breach
Frame size	64 KiB	close `4400`
Client frames per second	20	close `4429`
Subscribed channels	200	`error`, subscribe rejected
Idle before ping	25 s	server sends `ping`
Missed pings tolerated	2	close `4503`
Token lifetime	12 h max	close `4401` at expiry

Per application

Limit	Value	On breach
Concurrent connections	20 000	connect refused, `4503`
Publishes per second	500 (burst 1 000)	`429` + `retry_after`
Publish body	64 KiB	`413`
Channels with traffic	50 000	`429` on new channels

Retention and replay

Each channel keeps the smaller of 5 minutes or 10 000 frames. A subscriber that reconnects with last_seq inside that window gets the gap replayed in order; outside it, the gateway answers with the current sequence number and a gap flag so the client knows to resynchronise from your own API rather than pretend it is caught up.

Replay is a convenience for reconnects, not durability. If losing a frame would be a correctness bug in your product, the source of truth has to be your database — publish the change, do not publish instead of writing it.

Availability

We target 99.9% monthly on WebSocket connects and on the publish API, measured the way status describes. Rolling restarts inside the announced maintenance window do not count against it — they close sockets with 4503, and a client that reconnects with jitter and last_seq loses nothing.

Fair use

One application per set of credentials. Reselling gateway capacity under your own brand needs a separate agreement.
No relaying of traffic you do not originate — this is a pub/sub gateway, not a proxy.
Abuse reports and takedown requests go to the address in the WHOIS record for this domain and are answered within two business days.