How to Create a Personal Access Token (PAT) in Airtable

Airtable quietly retired its single, account-wide API key in favor of Personal Access Tokens — a credential model borrowed from modern developer tooling. The change matters because the old API key granted full access to every base under your account. A PAT, by contrast, carries only the permissions you explicitly assign and only reaches the bases you specifically include. That means tighter security and simpler auditing across every integration you build.

If you connect Airtable to Make, Zapier, or any custom script, you will need a PAT. This guide covers what PATs are, how to create one step by step, how to drop it into the tools you already use, and how to manage tokens responsibly over time.

Video Tutorial

What a PAT Is and How Scopes Work

A Personal Access Token is a string that begins with pat followed by a long alphanumeric sequence. When you (or a tool acting on your behalf) sends a request to the Airtable API, the token travels in the HTTP Authorization header and tells Airtable three things: who you are, what actions are permitted, and which bases can be touched.

Scopes are the individual permissions attached to a token. Airtable groups them into several categories:

For most integrations — pulling records into Make, pushing form responses from Zapier, or querying data from a script — you only need data.records:read, data.records:write, and schema.bases:read. Adding more scopes than necessary widens the blast radius if a token is ever exposed.

Resource access is the second dimension. In addition to scopes, you specify which bases the token can reach. You can technically grant access to every base in your account, but the recommended approach is to restrict each token to the exact bases the integration requires.

Step-by-Step: Create a PAT in Airtable

The entire process takes under two minutes.

Step 1: Go to the token management page

Log into Airtable and navigate to airtable.com/create/tokens. This page lists all tokens you have created and lets you create new ones.

Step 2: Click "Create new token"

A panel slides open with three configuration sections: name, scopes, and base access.

Step 3: Name the token clearly

Use a name that identifies the integration it belongs to, for example Make – Hotel Incident Reporting or Zapier – CRM Sync. A clear name makes it easy to spot which token to revoke when an integration changes.

Step 4: Add scopes

Click "Add a scope" and select each permission your integration needs. For a standard read/write automation:

• data.records:read
• data.records:write
• schema.bases:read

If your tool needs to create fields or tables via the API, also add schema.bases:write. Skip webhook and block scopes unless the integration explicitly requires them.

Step 5: Restrict base access

Under "Add a base," search for and select the specific base (or bases) this token should reach. Avoid selecting "All current and future bases" — it defeats the purpose of scoped credentials.

Step 6: Click "Create token" and copy immediately

Airtable displays the token value exactly once. Copy it to your clipboard and paste it directly into the integration tool or store it in a password manager. Once you close or navigate away from the dialog, the value is gone — only the token name and its settings remain editable.

How to Use a PAT with Make, Zapier, and cURL

Make (make.com)

Make has native Airtable modules that handle authentication through a named connection. To connect:

1. Add any Airtable module to your scenario (for example, "Search Records").
2. Click Add next to the Connection field.
3. Give the connection a name (use the same descriptive name as the token itself).
4. Paste your PAT into the API token field.
5. Click Save.

Make now uses that connection for every Airtable module in the scenario. Because the PAT was scoped to specific bases, the connection will only show those bases in the module dropdowns — a useful built-in safeguard.

For more complex Airtable workflows built in Make, see our Airtable automation guide.

Zapier

Zapier also has a first-party Airtable integration. When you connect a new Airtable account in a Zap:

1. Choose Airtable as the app and select any trigger or action.
2. Click Sign in to Airtable.
3. Zapier will prompt for an API token — paste your PAT here.
4. Confirm the connection.

Zapier stores the token against the connected account and reuses it across all Zaps that share that connection.

Direct API calls with cURL

When you want to query Airtable from a terminal, a script, or a Make HTTP module without using the native Airtable connector, pass the PAT as a Bearer token in the Authorization header:

curl -X GET "https://api.airtable.com/v0/YOUR_BASE_ID/YOUR_TABLE_NAME" \
  -H "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN" \
  -H "Content-Type: application/json"

Replace YOUR_BASE_ID with the base ID from your Airtable URL (it starts with app), YOUR_TABLE_NAME with the URL-encoded table name, and YOUR_PERSONAL_ACCESS_TOKEN with the pat… string you copied at creation. A successful response returns HTTP 200 with a JSON payload containing your records.

The Airtable API documentation — accessible from any base by clicking Help — shows the exact endpoint URL and sample responses for each table in that base, which makes it easy to confirm the correct base ID and field names before writing a full integration.

Security Best Practices

Getting authentication working is the easy part. Keeping it secure over time requires a few deliberate habits.

Create one PAT per integration. Treat each connected tool — Make, Zapier, a Node script, a third-party app — as its own identity. If you ever need to revoke access for one of them, you delete that token without disrupting the others.

Apply the principle of least privilege. Before adding a scope, ask whether the integration actually needs it. A Zap that only reads records has no reason to hold write or schema permissions. Scopes can be added later if requirements change.

Never expose a token in public. Tokens should not appear in video recordings, public GitHub repositories, shared Notion documents, or error logs. If a token is ever accidentally exposed, delete it immediately from airtable.com/create/tokens and create a replacement.

Rotate tokens periodically. Even without a known compromise, replacing tokens on a regular schedule (every 90 days is a common policy) limits the window of exposure for any token that may have leaked without your knowledge. Airtable makes this straightforward: create the new token, update the integration, confirm it works, then delete the old one.

Document which token belongs to which integration. A simple internal record — a note in Airtable itself, a shared password manager entry, or a Notion page — that maps token names to their purpose prevents the guesswork of "what does this token do?" when you need to audit or clean up. For a deeper look at how Airtable handles data protection overall, see our Airtable security guide.

Business Use Cases

PATs are the foundation of almost every Airtable integration that runs outside the browser. Here are the scenarios where they appear most often:

Automation platforms. Any Make scenario or Zap that reads from or writes to Airtable uses a PAT under the hood. Separating tokens by workflow — one for CRM syncing, one for inventory updates, one for client reporting — makes troubleshooting far easier when something breaks. See Airtable automation examples for ideas on what to build.

Custom scripts and internal tools. Developer teams that query Airtable from Python, Node.js, or other languages use PATs in environment variables. The script never hardcodes credentials; instead, it reads the token from a secret manager or environment configuration at runtime.

Third-party SaaS integrations. Many tools — project management apps, form builders, reporting dashboards — offer Airtable connectivity that requires you to paste a PAT during setup. Scoping that token narrowly means the third-party app can only access the bases it needs.

API-driven schema management. Teams that build and maintain large Airtable bases sometimes script field and table creation. These scripts require a token with schema.bases:write, which is why that scope is kept off by default.

When to Hire Help

Setting up a single PAT is a beginner-level task. The complexity comes when you need to build and maintain the automations that use those tokens at scale. Consider working with an Airtable consultant when:

• You are connecting Airtable to five or more tools and need a coherent credential management strategy.
• You need to build multi-step Make scenarios that combine Airtable with other APIs and custom HTTP modules.
• Your team stores sensitive data in Airtable and needs a full security review, not just token setup.
• You want to automate schema changes — creating fields and tables programmatically — as part of a larger deployment pipeline.

A Make automation agency can design the full integration architecture, implement scoped tokens correctly from the start, and hand off documentation so your team can manage it going forward.

Next Steps

With a PAT in hand, you are ready to connect Airtable to the rest of your stack:

• Follow the Airtable automation guide to build your first Make scenario using the token you just created.
• Browse Airtable automation examples to see what real business workflows look like end to end.
• If you work with sensitive client or business data, read the Airtable security guide to understand how Airtable protects data at the platform level.
• Ready to go deeper with Make or Zapier? Our Zapier automation page covers how to structure multi-step Zaps that scale without becoming a maintenance burden.

Personal Access Tokens are a small configuration step that unlocks everything Airtable can do as a connected platform. Get the scoping right from the start, document what each token does, and you will have a secure, maintainable integration foundation for every automation you build on top of it.