Due to increased popularity, the API needs to have rate limits added to ensure that it can continue functioning properly. This is going to be a bumpy transition, but here’s what I’m thinking so far —
- The rate limit is per-IP,
- Global across all endpoints (e.g., separate endpoints do not have separate rate limits),
- Is (probably) tracked on a per-minute basis, and
- Is continuously updated, rather than resetting at a specific interval.
The main change is that, upon reaching the rate limit, more requests just return “HTTP 429 Limit Exceeded” with the response body {"error":“rate limit exceeded”}. Rate-limited requests still count against the limit (this is an implementation detail of the existing backend service that manages limits). Additionally, responses will contain a new header:
- X-Rate-Limit-Limit is the maximum number of requests that may be issued within a minute. This is a static value doesn’t contain count for requests you have already sent.
At some point in the future I’d like to add X-Rate-Limit-Remaining, which would contain the actual number of requests that can still be made before hitting the limit, but that needs more extensive backend changes to support.
For the actual limit, the current number I’m thinking of is 600 requests/minute. I think that’s enough to pull all of the trading post listings every 30 seconds (which is how long they’re cached for). The limit is a rolling limit, so if an application makes 600 requests, then waits for 30 seconds, it should be able to make another 300 requests without going over.
This isn’t set in stone yet, so let me know if you have feedback/concerns/questions. Rate limiting does need to be implemented before the API can be turned back on, though, otherwise the API will just continue falling over. I would like to get everything back up and running on Monday, but the schedule might slip a bit if something unexpected happens.
