How to build a client portal on Airtable

A client portal is the build people ask about most, and the one that goes wrong most quietly. The requirement sounds simple — everyone signs in and sees their own records — and Airtable is a natural home for the data. The trap is that the obvious way to build it works perfectly in testing and exposes everything in production.

The one rule

Every portal has exactly one rule underneath it: no member can ever see another member's data. Not by guessing a URL, not by opening the network tab, not by any other means.

Everything else — the design, the fields, the pages — is detail. If you get this wrong, nothing else matters. If you get it right, the rest is ordinary work.

Why the obvious build fails

The obvious build is a front end that calls the Airtable API directly. It's fast, there's nothing in between, and it works on your laptop.

It fails for two reasons that have nothing to do with how carefully you write it.

A browser cannot keep a secret. Any API key your front-end code uses has to be sent to the browser to work. Anyone can open the network tab, or read the JavaScript bundle, and take it. There is no clever way around this — obfuscating it, splitting it, fetching it at runtime all end the same way. If the browser can use the key, a visitor can take the key.

Airtable's API has no per-user permissions. That one key reads and writes every record in the base. There's no way to say "this key may only see rows belonging to Sarah." Once someone has it, they have the whole base — every member, every document, every record.

Put those together and the failure is complete. Hiding rows in the interface doesn't help, because the interface isn't what's being attacked. Someone calls the API directly and pulls everything.

What actually makes it safe

Something has to sit between the browser and Airtable, holding the key and deciding what each request is allowed to see. That's the whole job. It can be your own server code, a managed service that does it for you, or a real database you sync into — but the shape is always the same:

1. The browser asks your server for data. It never talks to Airtable.
2. Your server works out who is asking, from their session.
3. Your server fetches only that person's records, using the key that never leaves it.
4. The browser gets back only what that person is allowed to see.

Step 3 is the one people skip. Fetching everything and filtering in the browser is the same bug wearing a different coat — the data still reaches the visitor.

The linked record is your privacy gate

In Airtable, the mechanism that makes step 3 possible is the linked record. Every table holding member-owned data needs a link to the member who owns it. That link is not a convenience for filtering views; it is the thing your server checks on every single read.

Design it in from the start. Retrofitting ownership onto tables that were built without it means backfilling every existing row and auditing every query you've already written, and it is much harder to be sure you caught them all.

Where this leaves you

None of this is exotic. It's one architectural decision — put something between the browser and the data — made early enough that the rest of the build sits on top of it rather than fighting it.

Two smaller decisions follow from it and are worth making early too. Signing people in with a one-time code by email means never storing a password, which is one less thing to get wrong. And admins almost always see everything, which makes the admin check load-bearing in exactly the way the member check is — it deserves the same care, not a flag on a record that a stray edit could flip.

The remaining question is what goes in the middle. That one is a genuine trade-off between cost, effort, and how much you are willing to maintain yourself, and the honest answer depends on what you're building and how much you've done before.