How to put a Next.js proxy in front of Airtable

Putting a Next.js app in front of Airtable is the standard answer to "you need something in between", and it is a good one. Your pages call routes you wrote, those routes call Airtable, and the browser never touches the base. The difficulty is that Next.js gives you the shape of the solution and none of the contents. The server is there. Everything you would want running on it, you write.

The line the key never crosses

Next.js runs your code in two places, and the whole design rests on knowing which is which. Anything marked as client code is shipped to the browser, where any visitor can read it, and so is every value a server component handed it as a prop. Route handlers run on the server, and that code never ships.

Your Airtable token lives in an environment variable that only server code can read. The route handler reads it, calls Airtable, and returns a result. What reaches the browser is the data you decided to send — not the token, not the structure of the rest of your base.

The easiest way to undo this by accident is the NEXT_PUBLIC_ prefix. Variables named that way are deliberately baked into the bundle so the browser can use them, which is exactly right for a public site URL and exactly wrong for a key. Nothing warns you. It works perfectly, for everyone.

Your routes are the only API the browser knows

Once the key is on the server, the front end should contain no Airtable client at all. No call to Airtable's API, no SDK, no "just this one read". Every screen calls a route on your own domain, and that route decides what it is prepared to return.

That is what buys you the things Airtable's API cannot do. You can filter by the signed-in person before anything leaves the server. You can drop fields the browser has no business seeing. You can reject a write that makes no sense. Airtable's API offers none of this — one key reaches the whole base, every table and every record — so the only place per-user rules can exist is in code you control.

Caching is what keeps you under the limit

Airtable allows roughly five requests per second per base. That sounds generous until you notice a single page view might be three or four calls, and that ten people opening a dashboard at the same moment is not a large audience. Past the ceiling, requests fail.

A proxy makes this solvable, because one call to Airtable can serve many visitors. Cache the response at your route and the second, third and hundredth request for the same list are answered by your server without Airtable being involved. Next.js gives you caching at several levels, along with ways to expire an entry when something changes.

The judgement is how stale each thing is allowed to be. A public listing that changes twice a week can sit for hours. A record someone has just edited has to be fresh, or your app looks broken to the one person guaranteed to notice. Two things to watch: attachment URLs from Airtable's API expire after a short window, so anything you cache for long should point at images you have copied somewhere durable rather than at the URL Airtable handed you. And per-user responses must never be cached under a key that ignores who asked. That is how one member's data ends up on another member's screen.

Next.js does not know who anyone is

There is no user table here, no session, no password reset, no email verification. A route handler runs for whoever calls it, and unless you have put something in the way, that is everyone on the internet.

So logins come from outside — a hosted identity provider, or an auth library you wire in and maintain. Whichever you choose, its job is the same: give each request a trustworthy answer to who is asking, before the route decides what to fetch. Every per-user filter hangs off that answer, which is why it has to be something the server verifies rather than something the browser simply asserts.

What you are signing up for

Total control, against building all of it yourself. Nothing in this stack limits what your app can do. Nothing in it does any of the work for you either.

The list is longer than it looks from the start: authentication and sessions, caching and knowing when to invalidate it, sensible behaviour when Airtable is slow or down, backoff when you hit the limit, validation on writes, and a deployment you keep patched. Each piece is ordinary work. Together they are why a small internal tool rarely justifies this route, and why anything you intend to charge money for usually does.