Hold your horses: introducing rate limiting to ESI
Hi all,
Today we're announcing the introduction of rate limiting to ESI. This is a significant change that will help ensure fair usage across all applications. Rate limiting will be implemented using a floating window system, and we'll be rolling it out gradually across different routes.
The first route that will be rate limited is /status, scheduled for the 13 October 2025.
Background
ESI has grown tremendously over the years, and with that growth comes new challenges. While we're thrilled to see so many developers building amazing tools with our API, some usage patterns have become problematic for the service as a whole.
Take the /status route, for example. It's cached for 30 seconds, so there's really no need to call it more often than that. Some applications use it to check if ESI is alive - which is perfectly reasonable. Once every 5 seconds sounds fair, right? Well, some applications decided to call it before every single ESI request. Or 10 times per second. This is not reasonable.
Then there's the /assets route: every hour on the hour, we see traffic spike to 100 times the normal rate. While we clearly have work to do to make asset access easier and not require downloading everything every hour, these traffic patterns are becoming increasingly difficult to handle. There's only so much you can scale.
These examples illustrate why we need rate limiting. It's not about restricting legitimate usage - it's about ensuring that everyone can use ESI reliably and fairly.
Introducing: Floating Window Rate Limiting
We're implementing a floating window rate limiting system that tracks token consumption over time. Here's how it works:
Each request consumes tokens based on the response status (2XX responses cost 2 tokens, 3XX cost 1 token, 4XX cost 5 tokens, and 5XX cost 0 tokens).
Tokens are returned to your bucket after 15 minutes.
One or more routes create a rate limit group.
Each rate limit group / ApplicationID / CharacterID combination gets its own bucket.
If you exceed the limit, you'll receive a 429 response with a
Retry-Afterheader (in seconds) indicating when to try again.
The system is designed to be fair and transparent. You'll see rate limit information in response headers, and the OpenAPI specifications will include rate limiting details for each route. More in-depth information about the rate limiting can be found in the documentation.
Will I Be Impacted?
To answer this, we have to give you a bit of insight how we monitor and configure the rate limits. Let's start with this image:
This image shows us how the char-location group is doing. This group is the /location, /online and /ship combined. Two have a cache time of 5 seconds, one of 1 minute. So, a reasonable assumption would be that the routes in the group combined won’t be requested more than once every 2 seconds, right?
The bottom line shows 90% of apps using less than 200 tokens in 15 minutes or making about 1 request every 10 seconds (assuming it is a 200 response).
The middle line shows 99% of apps using less than 1000 tokens in 15 minutes or making about 1 request every 2 seconds. All applications are expected to be at or below this line.
The top line here shows 99.9% of apps using less than 1800 tokens in 15 minutes or making about 1 request every second. These applications ask for location data twice within the cache time, which doesn’t produce any new information.
Newly set rate limits will be somewhere between 99% and 99.9%. The 99% we consider reasonable, and the 99.9% - excessive. This also means only 0.1% of the traffic (which accidentally also translates to ~0.1% of the applications) will be impacted.
Wrapping up
For most applications, this change should be invisible. The rate limits are generous enough that normal usage patterns won't be affected. However, if your app is currently making requests in bursts or hitting the same endpoints very frequently, you might need to adjust this approach.
We'll be rolling out rate limiting gradually across different routes. Our tentative timeline is:
13 October 2025: status group
27 October 2025: factional-warfare, incursions, insurance, routes, sovereignty groups
30 October 2025: fitting, fleet, industry, notification, UI groups
3 November 2025: location group
6 November 2025: killmail-related groups
10 November 2025: corporation-related groups
13 November 2025: character-related groups
24 November 2025: asset-related groups
27 November 2025: contract-related groups
Cheers,
Your friendly developers of the EVE Strict Interaction (working title)