Current backend rules
These are the current Maxlona defaults. Limits follow the organization and signed-in identity instead of the caller's network, so coworkers behind one office connection do not consume a single shared allowance.
| Traffic | Limit | Applies to |
|---|---|---|
| HTTP API, SDK evaluation, and GraphQL | 80 / second | Organization |
| Management Key safety limit | 40 / second | Individual key, stored as a hash |
| Browser console | 20 / second per user; 200 / second org ceiling | Signed-in user and organization |
| Login, signup, MFA, password recovery, and public contact | 10 / 10 seconds | Client network address |
| Unauthenticated or invalid-credential API traffic | 60 / second | Hashed client network address |
| Support tickets | 5 / hour and 20 / day | Signed-in user |
What this means by surface
Fairness per person
Each signed-in user has an independent allowance, with a larger organization ceiling protecting overall capacity. Sharing an office network does not make colleagues throttle one another.
One organization budget
REST management and evaluation calls share the organization's API allowance. Creating extra keys does not expand that allowance; each key also has its own safety limit.
One request, bounded work
GraphQL shares the organization API allowance. A document may invoke at most 25evaluate fields, preventing aliases from multiplying evaluation work without bound.
GraphQL evaluation budget
The 25-evaluation budget is per GraphQL document and is separate from the organization and key request limits. Exceeding it produces a GraphQL error with code EVALUATION_LIMIT_EXCEEDED and status metadata 429. Split larger batches across requests and pace those requests normally.
{
"errors": [
{
"message": "A GraphQL request may evaluate at most 25 flags. Split the evaluations across requests.",
"extensions": {
"code": "EVALUATION_LIMIT_EXCEEDED",
"status": 429
}
}
]
}Realtime streaming limits
SignalR connections have separate limits because a connection remains open instead of consuming one ordinary API request. Limits are enforced across application instances.
When a connection limit is reached, normal clients receive a 429 during negotiation. Clients that skip negotiation receive a connectionRejected event before the connection is closed.
Handling HTTP 429
A pipeline rate-limit rejection returns HTTP 429 Too Many Requests with a JSON message. Treat it as temporary. The current backend response does not guarantee a Retry-After header, so clients must have a fallback delay.
{
"code": "rate_limit_exceeded",
"message": "Rate limit exceeded for api. Maximum 80 requests per configured window.",
"bucket": "api",
"retryAfterSeconds": 1
}Recommended
- Honor
Retry-Afterwhen a gateway or deployment supplies it. - Otherwise use exponential backoff with jitter.
- Cap retries and expose the final failure to the caller.
- Cache stable evaluations where your consistency needs allow it.
Avoid
- Immediate retry loops from every SDK instance.
- Retrying validation, permission, or not-found errors.
- Sending parallel retries with the same key.
- Using key rotation to evade a legitimate limit.
Backoff example
const retryAfter = response.headers.get('Retry-After');
const serverDelay = retryAfter ? Number(retryAfter) * 1000 : undefined;
const fallback = Math.min(250 * 2 ** attempt, 10_000);
const jitter = Math.random() * Math.max(100, fallback * 0.25);
await delay((serverDelay ?? fallback) + jitter);Diagnostics and Error Logs
A 429 from public API usage is a client integration event, not a Maxlona internal exception. Editors and Admins can review it under Error Logs, where rate-limiting events are grouped without storing raw keys, request bodies, evaluation context, or stack traces.
If traffic stays below the documented limits but receives 429 responses, inspect the returned bucket, coordinate concurrent callers within the organization, and provide the response trace ID to support when one is present.
Standard client error envelope
Public API errors can include a stable code and trace ID. Preserve the trace ID in client logs, but never log the Management Key or evaluation context.
{
"status": 400,
"code": "validation_error",
"message": "Title is required and must be 200 characters or less.",
"traceId": "00-79ab…3d-01"
}Common statuses include 400 validation, 401 unauthenticated, 403 forbidden, 404 not found, 409 conflict, 429 rate limited, and 503 unavailable. Do not retry ordinary 4xx errors other than 408 or 429 unless the response specifically describes a recoverable action.