The rate limit you inherit
When you pick a platform you also pick its rate limit, and almost nobody reads that page before signing up. Airtable caps its web API at 5 requests per second per base. Webflow gives a Starter or Basic site 60 requests per minute to the Data API. Notion allows a connection 180 requests per minute unless the workspace is on Business or Enterprise. Those numbers are published, they are honest, and they are not negotiable at your tier. The interesting part is what they do to the software you build on top.
The published numbers
Airtable's rate limit page states it plainly: 5 requests per second per base, plus a separate 50 requests per second ceiling across all traffic from one personal access token or service account. Go over and you get a 429 and a 30 second penalty before anything succeeds again. Airtable also reserves the right to change the enforced limits, including tiering them by plan, and recommends a caching proxy if you expect real read volume.
Webflow ties the limit to the site plan. Starter and Basic get 60 requests per minute to the Data API. CMS, eCommerce and Business get 120. Enterprise is whatever you negotiate. Publishing is capped separately at one successful publish per minute. Cached reads through the content delivery API do not count, which matters, but every uncached origin read does.
Notion splits it in two. A connection gets 180 requests per minute on most plans and 600 on Business or Enterprise, spendable as a burst or spread out. On top of that sits a shared per workspace budget, so your integration can be well inside its own limit and still get a 429 because something else in the workspace is busy. Notion's docs say outright that the limits may change to balance demand and reliability.
Where the arithmetic starts to hurt
One integration polling politely never notices any of this. The trouble starts when the second and third integrations arrive, because the ceiling is shared and nobody is coordinating. Five requests per second per base sounds generous until a nightly reconciliation job, a Zapier automation and a customer facing page all want the same base in the same second. The reconciliation wins, the other two collect 429s, and the 30 second lockout means a burst of failures rather than a graceful slowdown.
Bulk work is where the number turns into wall clock time. Airtable's list endpoint pages 100 records at a time, so walking 50,000 records is 500 requests, which is at least 100 seconds at 5 per second, during which the base has nothing left for anyone else. On a Webflow Basic site at 60 per minute, one request per second is your entire budget across every key holder and every integration. You cannot buy your way out of that with better code. You buy your way out with a higher plan, or you cache, or you wait.
What makes this specifically a platform problem rather than an engineering problem is that you cannot see inside it. When our own Postgres gets slow we look at the query plan, add an index, change the access pattern. When a platform returns 429 there is no plan to read. The fix is a queue, a backoff, a cache layer, and a growing pile of code whose only job is to be patient with somebody else's infrastructure.
What changes when the ceiling is yours
On Stay World Class we replaced Webflow and Xano with Next.js, NestJS and Supabase. The migration ran as a four stage ETL that mapped every legacy ID to a PostgreSQL UUID so nothing lost its history. Lighthouse went from 55.91 to 91 out of 100 and LCP got 77 percent faster. The part that does not show up in a Lighthouse score is that the request ceiling stopped being a published figure on somebody's docs page and became a property of a database we could measure, profile and resize.
That is the honest version of the pitch. Owning the backend does not give you infinite throughput. It gives you a limit with a cause. Slow means a missing index or an undersized instance, both of which you can fix this afternoon. It also means a batch job can hammer the database at three in the morning without a nightly report and a signup form fighting over the same five requests per second.
The reason this argument works now and did not work in 2021 is that building the replacement used to be the expensive part. AI assisted engineering closed most of that gap. The speed advantage that made Airtable and Webflow the correct choice is much smaller than it was, while the ceiling is exactly where it has always been.
When the ceiling is fine
Most teams on these platforms will never touch the limit, and they should stop reading here. If you have one integration, a few thousand records and traffic that reads through Webflow's CDN rather than the origin, 60 requests per minute is not a constraint you will ever feel. Paying engineers to rebuild something that works is a worse use of money than the plan upgrade.
Staying is also right when the upgrade solves it outright. Webflow CMS doubles you to 120 per minute. Notion Business takes a connection from 180 to 600. If the numbers you need sit inside the next tier and the tier costs less than a fortnight of engineering, take the tier. The same goes for read heavy workloads, where a cache in front of the platform removes the problem for a fraction of a migration.
The case for moving is narrower than the marketing on either side suggests. It applies when several systems compete for one shared budget, when bulk jobs are measured in minutes of pure waiting, or when the thing being throttled is a customer facing path rather than an internal sync. If you recognise your own architecture in that description, the rate limit is no longer a detail of the platform. It is the shape of your product.
