Load balancer
How Blazeauth resolves the right WebSocket endpoint before a session starts.
Load balancer is the HTTP entry point used before opening a WebSocket
session. Client makes one small HTTPS request and receives a ready-to-use
WebSocket endpoint.
What it does
- Selects a server compatible with the requested API version.
- Avoids sending clients to offline or overloaded nodes.
- Prefers a nearby server when client location can be determined.
- Returns one final endpoint, so client does not need to probe multiple nodes.
Why it is fast
The balancer adds only one compact HTTPS request before the WebSocket handshake. Client does not need to test several servers on its own. By design, the balancer request path is intentionally lightweight, so under normal conditions its own processing overhead should stay small compared to the network round-trip itself. Exact latency is not guaranteed and still depends on client-to-server distance, TLS handshake cost, and infrastructure health.
Request
Current client flow uses:
GET https://balancer.blazeauth.net/v1/websocket/serverv1is the API version segment.- Client should use the path that matches the WebSocket API version it supports.
Success response
{
"endpoint": "wss://eu-1.blazeauth.net/ws",
"location": "Frankfurt"
}Prop
Type
Error response
{
"error_message": "no servers are currently available",
"error_code": 100
}Prop
Type
Balancer error codes
| Code | Error | What it means |
|---|---|---|
100 | no servers are currently available | Balancer currently has no usable WebSocket nodes to return. |
101 | no servers are currently online | Matching servers exist, but none of them are currently online. |
102 | no servers with this version are available | No server is currently available for the requested API version. |
Client rules
- Call the balancer when starting a brand-new session.
- Treat
endpointas the final WebSocket URL. Do not rewrite it. - Use
locationonly for UI, logs, diagnostics, or telemetry. - Current balancer contract does not issue a separate handshake token.