You are about to ship an API, and one small decision is holding up the release: when a client gets close to its limit, which header do you send back? You have seen X-RateLimit-Remaining in a dozen places. You have also seen talk of a newer, unprefixed RateLimit header. You want to know what other providers actually do before you commit.
The HTTP Headers section of apis.io is built to answer that. It lists every header declared in published API contracts across the catalog. Its build scanned 159,590 specification files from 27,956 providers and observed 6,666 distinct header names. Of those, 308 get a page, because they are registered with IANA, reached by a regulation, or declared by at least 25 providers. The other 6,514 are real, but mostly one-off vendor fields.
You open the Rate Limiting and Quota category, which has nine headers and three generations of practice. Retry-After is at the top: 329 providers, 13,027 spec files, and the only one of the group with a standard behind it, IANA and RFC 9110. Next comes the older X-RateLimit-* triplet. Limit and Remaining are each declared by 130 providers, and Reset by 107. Then there are the unprefixed fields from the IETF HTTPAPI working group. RateLimit is on 35 providers and RateLimit-Policy on 32. Both are still drafts, which is why neither is IANA-registered. Each is declared by about a quarter as many providers as the X- form.
You might read that as the market slowly moving to the new standard. So you click into the 35 providers on the RateLimit page, and the picture changes. At least 19 of them are UK banks or the UK Open Banking standard itself: Lloyds Banking Group, Bank of Scotland, Santander UK, Coutts, First Direct, Chase UK, Kroo, Monument, Tandem, Shawbrook, Paragon and others. They did not each choose the IETF draft on their own. They publish versions of the same standard-derived contract, so they inherited the header together. The rest of the list is a mix of individual companies, including Honeycomb, MessageBird, Dow Jones, Triple Whale and Anchor Browser. Outside UK banking, the move to the standard header looks like individual choices, not a market trend.
You also notice how the numbers are counted. RateLimit-Policy shows up in 8,006 spec files from only 32 providers, because banks repeat it on every operation of every versioned contract. If you had compared by file count, the draft would look far bigger than it is. Provider count is the fairer measure.
Here is the part that makes you trust the section more. The catalog turned the section on its own record and found three problems. The headline counts disagree: the category page counts Retry-After on 330 providers and RateLimit on 36, while the header pages say 329 and 35, because the two pages are built at different points in the same run. The section description is out of date, saying headers were assembled from 119,030 specification files when the summary data counts 159,590. And the spec-file counts are heavily skewed, as you just saw. None of this changes the shape of the finding, but it tells you to read the figures as approximate.
You also keep the section's own caveat in mind. The counts are what a published contract declares, not what a deployment sends. Many APIs that return X-RateLimit-Remaining in production never mention it in their OpenAPI. So these numbers measure documentation, which is what an agent reads before it makes its first call.
You close the tab with a plan. You will document Retry-After, which most providers already do. Then you will decide between the X- triplet that clients already parse and the draft standard that only a single regulated market has adopted. You know that choice rests on who your clients are, not on a trend that turns out to be one market's inheritance.
Read the original: https://apis.io/2026/11/12/the-headers-section-finds-130-providers-on-x-ratelimit-and-35-on-the-standard-most-of-them-uk-banks/