I work on OnePassApps. We build browser apps that run in your tab, and behind them sits one small API host. I have been reading its response headers this week, and the rate limit in them is not one number.
Two tiers, not one
Every answer from the API host carries x-ratelimit-limit, x-ratelimit-remaining, x-concurrency-limit, x-concurrency-remaining and x-request-id. I asked for 8 routes twice each - 16 requests - and the limit value was not the same on all of them.
| Route | Status | x-ratelimit-limit |
x-ratelimit-remaining |
|---|---|---|---|
/api/plans |
200 | 1200 | 1183 |
/api/plans |
200 | 1200 | 1182 |
/api/apps |
404 | 1200 | 1181 |
/api/apps |
404 | 1200 | 1180 |
/api/guest-data/signaldesk |
200 | 1200 | 1193 |
/api/guest-data/signaldesk |
200 | 1200 | 1192 |
/api/guest-data/movie-tracker |
200 | 1200 | 1191 |
/api/guest-data/movie-tracker |
200 | 1200 | 1190 |
/api/guest-data/word-counter |
404 | 1200 | 1189 |
/api/guest-data/word-counter |
404 | 1200 | 1188 |
/api/vote |
404 | 1200 | 1173 |
/api/vote |
404 | 1200 | 1172 |
/api/votes |
404 | 1200 | 1171 |
/api/votes |
404 | 1200 | 1170 |
/api/voting |
200 | 600 | 597 |
/api/voting |
200 | 600 | 596 |
There are two tiers in the same header on the same host:
- 1 route answered 200 and read
600:/api/voting. - 3 routes answered 200 and read
1200:/api/guest-data/movie-tracker,/api/guest-data/signaldesk,/api/plans. - 4 routes answered 404 and read
1200:/api/apps,/api/guest-data/word-counter,/api/vote,/api/votes.
So the number in the header is not one budget for the whole host. The tier tracks the route, not the outcome: the 4 paths that do not exist answered 404 and still read 1200, and among the 4 that answered 200 one read 600 and 3 read 1200. Only one route in this set sits in the lower tier, so this run cannot say how many routes share it - that is the honest limit of what these 16 requests show.
The remaining counter moves, the concurrency counter does not
x-ratelimit-remaining is the interesting one. Across the 16 requests it read 596, 597, 1170, 1171, 1172, 1173, 1180, 1181, 1182, 1183, 1188, 1189, 1190, 1191, 1192, 1193 - 16 different values, and it counted down as the requests went out.
x-concurrency-limit read 4096 and x-concurrency-remaining read 4095 on every single answer. 16 requests, 1 distinct value - the concurrency counter did not move while the rate counter was walking.
The natural reading is that the rate counter is a window budget that counts requests down and the concurrency counter is an in-flight gauge - but only the rate counter's behaviour was seen changing here. On this evidence the concurrency counter stayed on 4095 across 16 sequential requests; whether a request in flight would move it was not tested.
x-request-id is the other useful name. Every one of the 16 answers carried one and all 16 were different strings, so it identifies the request rather than the route - the value a support answer can quote.
What this is not
- One host, one day, 11 November 2026. Plain HTTPS, signed out, no cookies, no JavaScript, GET requests only.
- 8 routes asked for twice each, one at a time. A busy client would see the counters behave differently.
- The window the rate limit is measured over is not stated in any header, and the tier of a route was not tested under load.
- These are the headers as sent. How the counters are computed inside the host was not inspected.
If you want to see the apps these routes belong to, they are at https://app.onepassapps.com/ and the guides are at https://app.onepassapps.com/guides.
Top comments (0)