Rate limits
500 requests a day, counted per key, reset at 00:00 UTC.
Headers on every response
X-RateLimit-Limit: 500
X-RateLimit-Remaining: 497
X-RateLimit-Reset: 1788220800| X-RateLimit-Limit | Requests allowed per day on this key |
| X-RateLimit-Remaining | Left today, after this request |
| X-RateLimit-Reset | Unix seconds at which the counter clears |
How the count works
The increment and the check happen in one atomic statement in Postgres, so parallel requests cannot race past the limit. Failed requests still count — a 401 does not, because it never reaches the counter, but a successful fetch you then throw away does.
/api/keys/status is free to call and does not increment anything.
Not enough?
Almost certainly you do not need more. The data changes once a quarter, so the right pattern is one fetch of history.json a day at most, cached at your end. 500 a day exists to stop a runaway loop, not to ration anything.
If you genuinely need a higher limit — a public app, a research pipeline, anything with real users behind it — open an issue on the repository and say what you are building. There is no paid tier and nothing to buy.
Caching
Responses carry Cache-Control: private, no-store. That is about the gate, not the data: a shared CDN cache on a metered route would serve one caller’s response to everyone and let the whole world past the limit on one key. Cache it yourself, as long as you like.