Connect your Airtable base

PortalTable reads your base through Airtable's API using a personal access token you control. This takes about five minutes and only needs to be done once per base.

Before you start

You'll need owner or creator access to the Airtable base you want to connect, and a few minutes in Airtable's developer settings. Read-only collaborators can't mint a token with write scopes.

1 · Create a personal access token

In Airtable, open Builder hub → Personal access tokens and create a new token. Give it a name you'll recognize later, like portaltable-sync.

1
Add the scopes PortalTable needs
Grant data.records:read, data.records:write, and schema.bases:read. Read lets portals display data, write lets approvals and uploads flow back, and schema read lets PortalTable list your fields when you map them.
2
Grant access to one base
Under Access, add only the base you intend to connect. Scope the token to a single base rather than your whole workspace — least privilege keeps the blast radius small.
3
Copy the token once
Airtable shows the token string a single time. Copy it now; you'll paste it into PortalTable in the next step.

Treat the token like a password

Anyone with this token can read and write the base it's scoped to. PortalTable encrypts it at rest and in transit, but never paste it into chat, email, or a shared doc. You can revoke and rotate it from Airtable at any time.

2 · Link the base in PortalTable

In the console, open Settings → Connections → Add base, or follow the onboarding flow on a fresh workspace. Paste the token and PortalTable will validate it and list the bases it can reach.

Onboarding walks first-time agencies through workspace setup before the base connection step.
1Seven guided steps — connecting Airtable is one of them.
2Tell PortalTable who you are so defaults fit your workflow.

4
Pick the base and primary table
Choose the base, then the table that represents your clients or projects. This becomes the backbone PortalTable scopes and maps against.
5
Confirm the connection
PortalTable runs a test read. A green status dot means the token, scopes, and base all check out.

3 · Map your fields

PortalTable doesn't assume your column names. You tell it which field is the client, the status, the owner, and so on. Mapping is how a portal block knows what to render.

Client / account: The field that identifies which client a record belongs to. Drives per-client scoping — map this first.
Status: A single-select that becomes the status pill clients see (In progress, In review, Blocked, Done).
Owner: The teammate responsible. Shown as an avatar; hidden from clients if you prefer.
Title & dates: The record name plus any milestone or due dates surfaced on the project timeline.

Unmapped fields stay private

Only fields you explicitly map appear in a portal. Internal notes, margins, and rate columns never leak — if you don't map it, clients can't see it.

4 · How sync stays fresh

PortalTable caches your base so portals stay fast even as bases grow past Airtable's own view limits. Edits in Airtable appear in portals within a minute; you can also hit Sync now to pull immediately. Writes from the portal — an approval, an upload — post back to your base in real time.

On a rolling schedule, typically under a minute. Heavy bases sync on a slightly longer cadence, and Sync now forces an immediate refresh.

Portals keep serving the last cached snapshot read-only, and the console shows a red connection status until you paste a fresh token. No client ever sees an error page.

Yes. Connect the base once, then scope it per client. Ten clients in one base means one connection and ten scoped portals.

Build a client portal

Turn this base into a live app.

Security & permissions

Lock down what each client sees.