Rate limits
Per-key limits, and why they are not per-IP.
| Endpoints | Limit |
|---|---|
/attacks | 30 requests/minute |
/firewall/** | 30 requests/minute |
/game-servers/** | 60 requests/minute |
/game-servers/*/files/** | 60 requests/minute, in a bucket of its own |
Exceeding one is a 429.
Keyed by token, not by address
Limits are counted against the bearer token, not the source IP. Two keys do not share a bucket, and one key used from twenty machines does.
That is usually the behaviour you want — a noisy CI job cannot exhaust the budget of the dashboard sitting on the same NAT — but it has a corollary worth planning for: scaling a script horizontally does not scale its rate limit. If you need more throughput, issue separate keys per workload rather than running the same key wider.
File calls have their own bucket
Walking a directory tree is naturally chatty, so it counts separately from power and status — a file loop cannot spend the budget a monitoring loop needs to ask whether a server is up.
What does not count against it is the part you would expect to: an upload or a download runs against the node, on a URL this API hands out. One call buys a transfer of any size. See Files.
Attack history is the tighter limit
/attacks sits at 30/minute rather than 60. If you are polling it, ask for the
window you actually need with from and to rather than paging back through all
of history — a narrow window is both faster and cheaper against the limit.