Rate limiting

How Blazeauth limits websocket traffic and how clients should react when the limit is hit.

Blazeauth uses two different kinds of limits:

How it is surfaced

Layer	What client receives	When it happens
WebSocket traffic limit	WebSocket close `4201` with reason `rate limit hit` or `rate limited, N seconds left`	Client traffic from one IP goes over the shared websocket limit.
Packet-specific throttling	Normal JSON response status, for example `TooManyRequests`	One packet has its own business-level throttling rules.

Close code vs status

WebSocket rate limits are currently surfaced through close code 4201. Packet-specific limits use normal JSON statuses such as TooManyRequests.

Current limit:

Limit	Window	Scope
`90` actions	`1 minute`	One client IP

If the limit is exceeded, the IP is temporarily blocked for:

Block duration
`5 minutes`

This limit counts:

What the client sees:

if the limit is crossed right now, server closes the socket with 4201 and reason rate limit hit
if the IP is already blocked, server closes the socket with 4201 and reason rate limited, N seconds left

One more practical detail

The packet that crosses the websocket limit can still finish normally. If that happens, the server closes the socket right after that response.

When the close reason contains N seconds left, that value is the backoff time.

Some limits belong to one packet and do not close the socket.

Create account has a separate limit for account creation without a license:

Limit	Window	Scope	Result
`3` accounts	`24 hours`	One client IP	JSON status `TooManyRequests`

Notes:

this limit applies to no-license account creation
server may include retry_after in the response
client should keep the socket open and retry later instead of reconnecting immediately

Global status code RateLimited exists in the public status enum, but current documented websocket throttling flows are primarily exposed through:

Handle WebSocket close 4201 as a rate-limit event for the current IP.
Treat N seconds left and packet retry_after as the authoritative backoff signal when present.
Do not spam ping frames; they participate in the same global session limit.
Do not assume session resumption bypasses throttling. Immediate reconnects can still be rejected.