Airtable's docs said 10. The live API said 25. Test everything.
The short version: the vendor docs said 10 records per request. The live API took 25. Docs, tutorials, and AI training data are all stale documents; test the real system before building on it.
In July 2026 I was building a reference skill: a structured body of Airtable platform knowledge that Claude can load and work from at an expert level. The build had one governing rule. No fact ships on authority. If a claim about the platform matters, it gets tested against the live API before it goes in.
That rule sounded like overkill until the first week, when it caught a fact that everybody agrees on and that happens to be wrong.
The claim everyone agrees on
If you have ever written code against Airtable's REST API, you know the batch limit: you can create at most 10 records per request. The official documentation said so. The SDK examples assumed it. Tutorials repeated it. Community forum answers cited it. Every AI model I asked stated it with full confidence, because every document it was trained on said the same thing.
It is exactly the kind of fact nobody re-checks, because there is nothing suspicious about it. Ten sources agree. Why would you test it?
Because ten sources agreeing is not evidence of anything except that they read each other.
Eleven records later
Verifying a limit is cheap. You build a request that exceeds it and watch it fail. So on a scratch base, I sent a create request with 11 records, expecting the API to reject it.
It returned 200. All 11 records were created.
So I kept going. Fifteen records: created. Twenty-five: created. Twenty-six is where the API finally pushed back, with a 422 status and a message that settled the question better than any document had:
422: A maximum of 25 records can be created per request
The real limit was 25. It had been raised from 10 at some point, quietly, with no changelog entry I could find and no update to the page that developers actually read. The entire written record around the platform still said 10, and the platform itself had moved on.
The error message knew more than the documentation
Notice where the truth finally came from. Not the docs, not a tutorial, not a model. It came from the platform's own validation layer, in the text of a rejection.
This is a general pattern, and it is worth internalizing. A platform's enforcement code is updated when the behavior changes, because it has to be. The prose describing that behavior is updated later, by a different team, on a different schedule, sometimes years later. When you need to know a system's real rules, the surest method is often to exceed them on purpose and read what comes back. The error message is documentation that cannot drift, because it is generated by the thing it describes.
The lag reaches everywhere, including the vendor's own AI tooling
Here is the detail that turned this from an anecdote into a principle for me. At the time I ran these tests, the stale number did not just live in old tutorials. Airtable's own documentation for its MCP server, the integration layer built specifically so that AI assistants can work with Airtable, still carried the old limit. The channel designed to feed current facts to AI was itself serving a stale one.
And it was not an isolated case. During the same build, another widely repeated claim fell: that certain computed field types cannot be created through the API. The written record said impossible. The live API, probed in 2026, said otherwise. Two load-bearing facts, both wrong in the same direction: the platform had gotten more capable, and the documents describing it had not noticed.
Training data is the stalest document of all
If the vendor's own docs lag, consider what that means for AI models, which are trained on snapshots of those docs plus every tutorial and forum answer that repeated them. When a model tells you the batch limit is 10, it is not malfunctioning. It is doing exactly what documents do: reflecting the world as of when they were written.
That reframe matters for anyone deploying AI in their operation. Vendor docs, tutorials, community answers, your own internal wikis, and a model's training data are all the same kind of object. They are documents. They were true once. None of them are the system. The moment a document's claim becomes load-bearing for a decision or a build, it stops being an answer and becomes a hypothesis, and hypotheses get tested.
Why this matters beyond one number
Ten versus 25 sounds like trivia. It is not, because constraints shape architecture. A data migration built around batches of 10 makes two and a half times the requests it needs, and under a per-base rate limit that is the difference between a sync that finishes comfortably and one that crawls. Worse than the slow sync is the feature that never gets built because a document said the platform could not do it, when the platform had been able to do it for months.
Every operation I walk into runs on assumptions like this. Someone read a doc in 2023, made a sound decision, and the decision outlived the fact it was based on. Vendors change behavior without ceremony. The systems keep running on the old assumption until somebody probes.
Verification as a routine, not an event
So the skill treats platform facts the way a good operation treats inventory: counted, dated, and re-counted on a schedule.
Every volatile claim in it carries an as-of date, in this case "tested live, July 2026." A monthly automated routine re-runs the probes against the live API and flags anything that drifted, so a fact that was true at release does not quietly become false in production. The same build also went through an adversarial security review before release, which caught three ways a client portal could leak one tenant's data to another, but that is a story for its own post.
The working rule underneath all of it is the closest thing I have to a professional creed: when a fact is load-bearing, two minutes of live testing on a scratch resource beats an hour of reasoning from documents. The docs said 10. The API said 25. Only one of them was in a position to know.
If your systems are older than your AI ambitions, the method explains where I would start, and a conversation is how engagements begin.