Every Airtable integration starts with the same question: where do I find the credential? Then a follow-up: what's a base ID? And another: what's the difference between a table ID and a table name?
This guide is the short reference. Every identifier Airtable uses, where to find each, and what each one is for.
Personal Access Token (Replaces API Key)
What it is: Your authentication credential — the secret you pass in API requests, Make connections, Zapier connections, and MCP server configurations. Replaced legacy API keys in early 2024.
Where to find: airtable.com/create/tokens.
How to create:
- Go to the URL above.
- Click Create new token.
- Name it (e.g. "Production sync token").
- Select scopes:
data.records:read— read records.data.records:write— create, update, delete records.schema.bases:read— read base/table/field metadata (required for many integrations).schema.bases:write— modify base structure (rare).webhook:manage— create webhook subscriptions.
- Pick which bases the token can access. Avoid all-workspace access unless you really need it.
- Click Create token.
- Copy the value immediately. Airtable shows the full token exactly once.
Format: Starts with pat, looks like patXXXXXXXXXX.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
How to use: Set as the Authorization header on API requests:
Authorization: Bearer patXXXX.YYYY
For Make/Zapier/n8n, paste it into the Airtable connection setup.
For a full walkthrough including OAuth alternatives for multi-user apps, see our PAT guide.
Base ID
What it is: The unique identifier for an Airtable base. Every API request, integration, or MCP connection targets a specific base by ID.
Where to find: Three ways.
Method 1: From the URL
Open the base in Airtable. The URL is:
https://airtable.com/appXXXXXXXXXXXXXX/tblYYYYYYYYYYYYYY/viwZZZZZZZZZZZZZZ
The app prefix followed by 14 characters is your Base ID.
Method 2: From the API docs
Go to airtable.com/developers/web/api/introduction. Click your base in the list — the Base ID is displayed prominently with copy-to-clipboard.
Method 3: From the metadata API
Authenticated GET https://api.airtable.com/v0/meta/bases returns all bases the token can access, each with its ID.
Format: Starts with app, exactly 17 characters total. Example: appXXXXXXXXXXXXXX.
Table ID
What it is: The unique identifier for a table within a base. Stable across renames — table names can change, but IDs don't.
Where to find: Two ways.
Method 1: From the URL
Open the table in Airtable. The URL is:
https://airtable.com/appXXXX/tblYYYYYYYYYYYYYY/...
The tbl prefix followed by 14 characters is the Table ID.
Method 2: From the API docs
On the same API documentation page for the base, each table is listed with its ID.
Format: Starts with tbl, 17 characters total. Example: tblYYYYYYYYYYYYYY.
Table ID vs Table Name in API calls:
# Both work:
https://api.airtable.com/v0/appXXXX/Tasks
https://api.airtable.com/v0/appXXXX/tblYYYYYYYYYYYYYY
# But the ID is safer — it doesn't break if someone renames the table.
Field ID
What it is: The unique identifier for a field within a table. Useful when field names contain special characters or you want renames not to break integrations.
Where to find: On the API docs page, click into a table — each field is listed with its ID.
Format: Starts with fld, 17 characters total. Example: fldZZZZZZZZZZZZZZ.
When you need it:
- Filtering by field ID instead of field name (more robust to renames).
- Working with the metadata API to programmatically inspect schema.
- Building dynamic apps that need to reference fields by stable identifier.
Most integrations use field names, which is fine for stable schemas. Switch to field IDs when renames are likely or names contain quotes/special characters.
Record ID
What it is: The unique identifier for a single record. Permanent — never changes for the lifetime of the record.
Where to find: Three ways.
Method 1: From the expanded record URL
Click a record to expand it. The URL is:
https://airtable.com/appXXXX/tblXXXX/viwXXXX/recYYYYYYYYYYYYYY
The rec prefix followed by 14 characters is the Record ID.
Method 2: Add a formula field
Add a formula field with the expression:
RECORD_ID()
It displays the Record ID for every row.
Method 3: From the API response
Every record returned by the API includes its ID:
{"id": "recYYYYYYYYYYYYYY", "fields": {...}}
Format: Starts with rec, 17 characters total.
Why it matters: Record IDs are the join key for any integration that syncs Airtable with another system. Store the Record ID on the external system, and the external system's ID on the Airtable record, so both sides can find each other unambiguously.
View ID
What it is: The unique identifier for a view within a table. Useful for API calls that should respect a view's filters and sort order.
Where to find: From the URL — viw... portion.
Format: Starts with viw, 17 characters total.
Use in API: Pass as the view query parameter to scope a list request to records visible in that view:
curl -G https://api.airtable.com/v0/appXXXX/Tasks \
-H "Authorization: Bearer pat_xxxx" \
--data-urlencode "view=viwZZZZ"
Workspace ID
What it is: The unique identifier for an Airtable workspace (the container of bases). Most users don't need this — bases are usually addressed directly. Relevant only for workspace-level metadata operations.
Where to find: Workspace settings, or via the /v0/meta/workspaces metadata endpoint.
Format: Starts with wsp.
Quick Reference Table
| Identifier | Prefix | Length | Where Found |
|---|---|---|---|
| Personal Access Token | pat | Varies | Created at airtable.com/create/tokens |
| Base ID | app | 17 chars | Base URL or API docs |
| Table ID | tbl | 17 chars | Table URL or API docs |
| Field ID | fld | 17 chars | API docs |
| Record ID | rec | 17 chars | Record URL, RECORD_ID() formula, API response |
| View ID | viw | 17 chars | View URL |
| Workspace ID | wsp | 17 chars | Workspace settings |
Common Mistakes
Mistake 1: Using a legacy API key in 2026 code. They stopped working over a year ago. Migrate to PATs.
Mistake 2: Committing PATs to git. They end up in attack scripts within hours. Use environment variables and add .env to .gitignore.
Mistake 3: Using a workspace-wide PAT. Scope tokens to specific bases. Workspace-wide tokens are blast radius waiting to happen.
Mistake 4: Confusing Base ID and Table ID. Both are 17 characters starting with three letters. The prefix tells you which is which: app for base, tbl for table.
Mistake 5: Hardcoding table names. If anyone renames the table, the integration breaks. Use Table IDs.
Troubleshooting
"Invalid API key" error. PAT was copied with extra whitespace, or you used a legacy key. Regenerate.
"Could not find what you are looking for" error. Base ID or Table ID is wrong, or the PAT doesn't have access to that base. Check the API docs page for the base — it lists exactly what the PAT can access.
"You are not authorized to perform this operation" error. PAT lacks the required scope. Add data.records:write for create/update/delete.
PAT was lost. You can't recover a PAT after creation. Revoke the old one and create a new one with the same scopes.
Next Steps
Now that you have the identifiers, the next step is making real API calls. See our Airtable API beginner's guide for end-to-end CRUD walkthroughs, Python guide for pyairtable usage, webhooks guide for real-time integration, and PAT guide for advanced token management.
