Skip to content
4 changes: 3 additions & 1 deletion docs/services/esi/best-practices.md
Original file line number Diff line number Diff line change
Expand Up @@ -73,12 +73,14 @@ Not abiding to the information transmitted can lead to your app being **banned**

### Error limit

ESI limits how many errors you’re allowed to get within a set time frame. Once you reach the error limit, all your request are automatically discarded until the end of the time frame.
ESI limits how many errors you’re allowed to get within a set time frame. This Limit uses a fixed time frame, in contrast to the Bucket Limit which is a sliding window. Once you reach the error limit, all your request are automatically discarded until the end of the time frame.

Error limit headers:
`X-ESI-Error-Limit-Remain` errors left in this time frame.
`X-ESI-Error-Limit-Reset` seconds left until next time frame and errors reset to zero.

These headers are mutually exclusive to those described in the Bucket based Rate Limit.

The details are explained in this blog post: [Error Rate Limiting](/blog/error-rate-limiting-imminent)

### Bucket Limit
Expand Down
2 changes: 2 additions & 0 deletions docs/services/esi/rate-limiting.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@ In most cases you should be fine with far less requests than the rate limit allo

For routes that do not have this new rate limiting enabled, there is still an older "error rate limit" active.
This allows at most 100 non-2xx/3xx responses per minute. After that, it will return 420s on all ESI routes, even those with the new rate limiting enabled.
The headers described in this document are mutually exclusive to those described in the Error Limit documentation found under "Best Practices".

!!! important

Expand Down Expand Up @@ -97,3 +98,4 @@ Each route in the same group will show the same `window-size` and `max-tokens`.
- If you need to burst, that is fine; just not every window-size.
- Use staggered scheduling for periodic requests when possible. Ideally not `*/5` cronjobs. But rather: 5 minutes after the last job was finished.
- Respect cache times to minimize unnecessary requests.
- For Error Limiting, see [Best Practices](./best-practices.md)