Configuring API rate limits
Rate limits protect your G8KEPR endpoints from abuse and runaway traffic by capping how many requests are accepted in a given window. G8KEPR evaluates three independent axes on every request — per-key, per-user, and per-IP — and rejects a request the moment any one of them is exceeded.
The three rate-limit axes
Each request is checked against all three limits at once. The most restrictive one wins.
- ▸Per-key — Caps traffic for a single API key. Use this to keep one integration, script, or environment from consuming your whole quota.
- ▸Per-user — Caps combined traffic across every key a user owns. This is your ceiling for a human operator or service account, regardless of how many keys they hold.
- ▸Per-IP — Caps requests from a single source address. It applies even to unauthenticated and public write endpoints, so it absorbs credential-stuffing and scraping before a key is ever evaluated.
When a limit is hit, the API returns HTTP 429 Too Many Requests, and responses may include a Retry-After header indicating how long the client should wait before retrying.
Choosing limits per tier
Every plan ships with sensible defaults, and higher tiers raise the ceilings:
- ▸Community — Conservative shared limits, best for evaluation and low-volume testing.
- ▸Starter / Pro — Higher per-key and per-user ceilings for production integrations.
- ▸Enterprise — Custom limits, including per-key overrides for high-throughput service accounts.
Tune the per-key axis first. It gives you the finest control and lets you isolate a noisy integration without lowering limits for everyone.
Tune your limits
- 1.Open your dashboard and go to the API Security rate-limit settings.
- 2.Set your ceilings for each axis. Keep per-user at or above the busiest single key.
- 3.Optionally add a per-key override for a specific high-volume key.
- 4.Save. Changes take effect without a redeploy.
Overrides are expressed as requests per window. For example, a configuration might look like:
{
"per_key": { "requests": 600, "window": "1m" },
"per_user": { "requests": 2000, "window": "1m" },
"per_ip": { "requests": 300, "window": "1m" }
}Setting per-IP too low can throttle legitimate users behind a shared corporate NAT or proxy. Raise it for known office ranges rather than loosening it globally.
To handle 429 responses gracefully in your client, see Understanding rate-limit responses. To scope keys before tuning, see Managing API keys.