You are planning an agent that will make a hundred calls to a third-party API, and you want it to stay under the limit and avoid a 429. So you open the Rate Limits collection on apis.io, find your provider, and see a tidy record with numbers in it. It is tempting to paste those numbers straight into a retry loop.
Before you do, the post says to look at one field first: how the record was produced. The collection holds one record per provider, and each record states its method. That field, the post argues, is the most important thing to read before you trust the limits inside.
Here is what you would find. Of the 11,877 records that state a method, 5,443 are generated, 4,416 are searched, 1,242 are marked none, 668 are probed, 95 are derived, 6 are harvested and 6 are unmarked. Generated and searched records together make up 83 percent of the collection. The six harvested ones are the account's own properties, including apis.io and API Evangelist.
The contents vary too. 6,005 records carry a list of limits, while 4,018 are empty. 1,274 are a harvest of numbers pulled from documentation, and 580 describe policies instead of numbers. Evidence is thinner than those counts suggest: 5,083 records are evidence-backed and 6,794 are not. 4,861 name 429 as the over-limit status, 6,815 leave that status null, and a few dozen say "unknown", "not documented" or "not published". 7,264 declare no rate-limit response headers.
You might read an empty record as a gap, but many are real findings. 1,424 descriptions begin by saying the provider does not publish its limits. Chimoney is typical: it says throughput depends on funded wallet balance and KYB status, not on a per-minute cap. If your provider looks like that, no number is hiding.
What does a good record look like? The post points to GitHub. Its record has 18 limits, each with a number, a window and a scope: 60 requests an hour per IP unauthenticated, 5,000 an hour per authenticated user, 15,000 for an app owned by an Enterprise Cloud organization, and separate per-minute limits for Git LFS. It is evidence-backed and names 429. Even so, its method is "searched". The catalog found those limits in GitHub's documentation, and GitHub did not hand them over.
Now comes the turn, and it is about the catalog's own record. Out of all 11,877 records that state a method, exactly one was published by the provider: Nylas. The catalog wrote, searched for or inferred the rest. The post says so plainly, and it does not dress the collection up as more authoritative than it is.
The Nylas record is built differently. Each limit has a metric, a timeFrame, an applies list and a reference link back to the specific documentation page, and the record is dated 2026-08-20. GitHub's limits use window, while Nylas uses timeFrame. If your agent reads both, it has to handle two vocabularies for the same idea, because the collection does not normalize them yet.
So when you budget calls from a generated limit, you are budgeting from the catalog's best reading of someone else's docs. The post calls that better than nothing, and it is also why every record carries method, evidence_backed and a provenance_date. Check those three fields before the numbers go anywhere near a retry loop.
What you take away is a short habit and a note for your own API. Read method, evidence_backed and provenance_date first, expect two field names for the same concept, and treat an empty record as possibly an honest answer. If you run an API yourself, the quickest way to replace the catalog's guess with your facts is to publish your limits in a machine-readable file, as Nylas did.
Read the original: https://apis.io/2026/11/12/one-of-11877-rate-limit-records-on-apis-io-was-published-by-the-provider-itself/