Data Freshness & Caching
The API automatically manages data freshness for every request. There is no mode segment in the URL — the cache strategy is smart by default, and you opt into a live re-scrape only when you need it.
GET /v2/users/dymerz ← cache-first, no quota cost
GET /v2/users/dymerz?refresh=true ← force live scrape, costs 1 daily request
(See Refresh Intervals for the full table of maximum data ages.)
How It Works
Default (no ?refresh): Every request checks the internal cache first. If the cached data is still fresh, it is returned immediately. If the cache is stale, the API scrapes the RSI website in the background, updates the cache, and returns the fresh data — all automatically, at no quota cost.
With ?refresh=true: Bypasses the cache and forces an immediate live scrape from the RSI website. The result is stored in the cache before being returned.
?refresh=true always costs quota.
It counts as 1 daily request even if the data hasn't actually changed. Only use it when you genuinely need the latest data from RSI right now.
Quick Reference
| Scenario | What to do | Quota cost |
|---|---|---|
| General use | No extra parameter | Never |
| Need guaranteed up-to-date data | Add ?refresh=true | 1 per call |
| Quota running low | No extra parameter | Never |
| Checking if data changed (polling) | Use ETags | Never |
Reading Freshness from Responses
Every response includes two timestamps:
| Field | What it tells you |
|---|---|
updatedAt | When the data was last scraped from the RSI website |
expiresAt | When the cached data may next be automatically re-scraped |
Once expiresAt has passed, the next request will trigger a background re-scrape automatically — no ?refresh=true needed. Use this timestamp to schedule your next poll rather than polling on a fixed interval.
Each endpoint group has a fixed maximum data age. See Refresh Intervals for the full table.
For quota limits and how to check your remaining balance, see Rate Limits & Quota.