How to Get Your Airtable API Key (Personal Access Tokens in 2026)
May 25, 2026
Airtable no longer has API keys. Legacy API keys were fully disabled on February 1, 2024, and they no longer authenticate against the Airtable API. What replaced them is the personal access token (PAT)—and that's what you create today wherever a tool still asks for an "Airtable API key."
This guide shows you how to create a personal access token, how Airtable's scope-and-base permission model works (the part that trips people up), and when to use OAuth instead.
Key takeaways
- Airtable API keys are gone. Create a personal access token (PAT) instead, in the Airtable Builder/Developer hub.
- A PAT is permissioned in two dimensions: scopes (what it can do) and base/workspace access (which data it can touch). Misconfiguring either is the most common cause of 401/403 errors.
- The token is shown only once at creation. Store it immediately; if you lose it, you revoke and recreate.
- Use a PAT for your own account or server. If you're building a product where other people connect their Airtable, use OAuth instead.
The change you need to know about
If you've found an older guide that says "go to your Account overview and copy your API key," that path is obsolete. Airtable phased keys out over three steps—deprecation notice in early 2023, no new keys from August 2023, and full shutoff on February 1, 2024. As of today, legacy keys return authentication errors. The only supported credentials are personal access tokens (for your own scripts and servers) and OAuth (for apps that act on behalf of other users).
So when a library or third-party tool asks for an "Airtable API key," you paste a personal access token in that field instead.
Step-by-step: create a personal access token
- Open the Builder/Developer hub. In Airtable, click your profile avatar in the top-right and choose Builder hub (labeled Developer hub in some accounts).
- Go to Personal access tokens. In the left navigation, open the Personal access tokens section.
- Create a token. Click Create token and give it a descriptive name—"Production server – CRM sync"—so you know later what uses it.
- Add scopes (the what). Click to add the capabilities your integration needs, such as
data.records:readanddata.records:writefor record CRUD, plus schema or metadata scopes if you need them. Scopes are additive—grant only what you use. - Set base/workspace access (the where). Under Access, choose which bases or workspaces this token can reach. You can grant all current and future bases (broad, high blast radius) or specific bases (the recommended least-privilege approach).
- Create and copy. Click Create token, then copy the value immediately and store it in a secret manager. Airtable shows the full token only once—if you lose it, you revoke it and create a new one.
The scope-and-base model (don't skip this)
This is the Airtable-specific detail that trips up most integrations. Unlike the old API keys—which were global and could touch everything your account could, with full CRUD—a personal access token is a two-dimensional permission object:
- Scopes = what the token can do. Read records, write records, read or modify schema, read metadata. Omit a scope and the token simply can't perform that operation, even on a base it can access.
- Base/workspace access = where it can do it. A token can be locked to a single base, or granted across all of them.
So a read-only token scoped to one CRM base and a full-access token across every ops base can live under the same Airtable user with very different risk profiles. The practical consequence: when a tool says "I did everything right but I'm getting 401/403," the cause is almost always a missing scope or a base that wasn't granted to the token. Configure both correctly before you paste the token into a tool.
Using the token in API requests
Airtable's Web API uses bearer-token authentication. Set the header:
Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN
Base IDs and table names go in the URL as before:
https://api.airtable.com/v0/appXXXXXXXX/YourTableName
When to use OAuth instead
A personal access token is right when you control the Airtable account—your own scripts, a server-side sync, internal automation. If you're building a product where other people connect their Airtable accounts (a multi-tenant SaaS with a "Connect Airtable" button), use OAuth 2.0 instead.
You register an OAuth integration in the same Builder/Developer hub (under OAuth integrations), provide your app metadata and an HTTPS redirect URL, and receive a client ID and client secret (the secret is shown once). The OAuth flow uses the same scope vocabulary as PATs, but the difference is that each customer consents and picks which of their bases to grant—so resource scoping happens per tenant, under the user's control, rather than being pre-set by you. Mailchimp and Stripe draw the same line: use the static credential for your own account, OAuth when many customers connect theirs.
Frequently asked questions
Where's my Airtable API key? There isn't one anymore—Airtable disabled API keys on February 1, 2024. Create a personal access token in the Builder/Developer hub and use it wherever a tool asks for an "API key."
What's a personal access token? A scoped credential that replaced API keys. Unlike the old global key, you choose exactly what it can do (scopes) and which bases it can touch (access).
Why am I getting a 401 or 403 even though my token is correct? Almost always a permissions gap: either the token is missing the scope for the operation (e.g., no data.records:write) or the base you're calling wasn't granted to the token. Check both in the token's settings.
Can I see my token again later? No. Airtable shows the full token only once, at creation. If you've lost it, revoke it and generate a new one.
PAT or OAuth? PAT for your own/single-account use; OAuth when other people connect their own Airtable accounts to your product.
Connecting Airtable alongside your other integrations
Generating one Airtable token is straightforward. The work compounds when your product connects Airtable and the other apps your customers use—each with its own credential model, token-visibility rules, and scope system (Airtable's two-dimensional PATs, Stripe's test/live keys, Mailchimp's data center suffix, and so on).
Unified.to handles that authorization layer for you. Unified manages the Airtable connection—OAuth or personal access token—and gives you pass-through access to the Airtable API through a single connection, so your customers get a clean "connect your account" experience and your team doesn't build and maintain per-vendor authorization and token-refresh logic. The same connection model spans 460+ integrations, so adding the next one is configuration, not a new auth build.
It's the same pattern that lets teams like Humi ship integrations in days rather than building each one in-house.