Why does the account endpoint call your daily quota a rate limit?

You have just learned that there are two different walls. Now meet the field name that makes people confuse them.

GET /user returns your account state. Called live on 2026-07-28 against a test account, the relevant part of the response is:

{"subscriptionType": "monthly",
 "apiRequests": 1632,
 "apiRequestsDate": "2026-07-28",
 "dailyRateLimit": 100000,
 "extraLimit": 0}

Read the field names literally and dailyRateLimit: 100000 says "your rate limit is 100,000". It is not. dailyRateLimit is the daily quota — wall one. The per-minute rate limit, wall two, does not appear in this response at all. It lives in the X-RateLimit-* headers, which come back on every response — so watching wall two costs you nothing extra, as long as you know to look somewhere else for it.

What goes wrong if you believe the name

You build a dashboard. It shows a gauge labelled "rate limit" reading 1,632 of 100,000, sitting comfortably at 1.6%. Meanwhile your ingestion job is being 429'd hundreds of times a minute and the gauge does not move, because the gauge is measuring the wrong wall. You spend an afternoon looking for a bug in the retry logic when the answer was that you were never watching the relevant number — which was arriving in a header on every single one of those responses.

The spec itself is honest about it. The description on the field reads "Daily API request limit" — the description says quota, the name says rate. When a name and its description disagree, the description wins. When both are unclear, an experiment wins. A field name is a label somebody chose under time pressure; it is not a definition.

Reading the response correctly

Three details that matter once you are computing anything from this:

apiRequestsDate scopes the counter. It is the date the count belongs to — and it is not necessarily today. On an account that has made no calls yet today, the response carries a stale date beside a stale non-zero count: it reads whatever the last active day was. The counter does reset, but it resets on the first call of the new day, not at midnight. So apiRequests / dailyRateLimit is a fraction of apiRequestsDate, and a dashboard that renders it as "used today" without comparing that field to today's date will report yesterday's usage as today's.

extraLimit is real allowance. It is additional purchased daily capacity, and ignoring it understates your headroom by exactly its value. The correct calculation is:

remaining today = dailyRateLimit + extraLimit − apiRequests

On the account above: 100,000 + 0 − 1,632 = 98,368 calls left.

/user is free. It is documented as not consuming API calls. So you can poll your own usage without the instrument affecting the measurement — a genuinely useful property, and one you should confirm rather than assume for any endpoint you plan to poll.

The habit this is really teaching

Two fields in this API describe limits and neither name tells you which limit it is. That is normal. Every API you use will have at least one field whose name is a small historical accident.

So: before you build logic on a field, read its description; if the description is thin, make one call and look at the actual value; and when you cache or expose it, rename it in your own code to what it means. A variable called dailyQuota in your codebase costs nothing and never confuses anyone again.

Try it now

Here is /user for a second account, trimmed to the fields the formula needs; the figures are illustrative. Unlike the test account above, its extraLimit is not zero. Compute its remaining calls with the formula, once with extraLimit and once without, and say how far off a gauge that ignored the field would be. Check apiRequestsDate against the date of the call before you trust either figure.

{"apiRequests": 41250,
 "apiRequestsDate": "2026-09-28",
 "dailyRateLimit": 100000,
 "extraLimit": 50000}

Find every place in your code that reads a limit field and check which of the two walls it is actually about.
Pick one field name in any API you use that you have never questioned, and go read its description. There is usually one.