Airtable Personal Access Tokens

Airtable personal access tokens (PATs) let your workflows authenticate to Airtable with a token that has explicit scopes and explicit base access — instead of a person's OAuth login. The token never expires on its own, and what it can touch is decided at creation time.

On Airtable Enterprise Scale plans, admins can create the same tokens from a dedicated service account in the Admin Panel. Those tokens are wire-identical to personal access tokens and are the better choice for organization-level use: they don't stop working when an employee leaves.

Prerequisites

Any Airtable user can create a personal access token for the bases they have access to. Keep in mind the token is capped by its creator's own permissions — a PAT created by a read-only collaborator cannot write, no matter which scopes it has. Create the token from an account with the access level your workflows need.

For service-account tokens, you need an Enterprise Scale plan and an admin with access to the Admin Panel.

Creating the Token

Open airtable.com/create/tokens and click Create token

Give the token a name (e.g. sim-airtable-bot)

Add the scopes your workflows need. The full set Sim's Airtable tools and triggers use is:

data.records:read
data.records:write
schema.bases:read
user.email:read
webhook:manage

Reading records needs data.records:read; creating, updating, upserting, and deleting records need data.records:write; listing bases and tables and reading base schemas need schema.bases:read; user.email:read lets Sim show the token owner's email as the credential name; and webhook:manage is only needed if you use Airtable triggers in Sim.

Under Access, add the bases or entire workspaces the token should reach. The token can only see what you list here — a token with all five scopes but no base access can't read anything.

Click Create token and copy it when it's shown. Airtable only displays it once — if you close the dialog, you'll have to regenerate it.

The token is bearer credentials for every base you granted. Treat it like a password — do not commit it to source control or share it publicly. Sim encrypts the token at rest.

Enterprise Scale: Service Account Tokens

On Enterprise Scale plans, an admin can create up to 30 service accounts (raisable via Airtable support) from the Admin Panel, each with its own name and email. From a service account's Personal access tokens panel, the admin creates tokens with the same scopes-plus-base-access builder shown above. The resulting token works in Sim exactly like a user PAT — same format, same pat… prefix, same behavior — but it belongs to the organization, not a person, so it survives employee offboarding. If your plan supports it, prefer this over a user-created PAT.

Enterprise organizations can enable "Block API access to organization-owned bases and workspaces". If your organization uses this setting, the service account must be allowlisted or every call fails despite a valid token.

Adding the Service Account to Sim

Open your workspace Settings and go to the Integrations tab

Search for "Airtable Service Account" and click it, then click Add to Sim and choose Add personal access token

Paste the Personal access token, and optionally set a display name and description

Click Add personal access token. Sim verifies the token by calling Airtable's whoami endpoint — if it fails, you'll see a specific error explaining what went wrong.

Validation only proves the token is real — Airtable doesn't expose a PAT's scopes or base access for inspection. A token that validates fine can still fail every tool call if you skipped a scope or forgot to grant base access. If a block returns a 403 (INVALID_PERMISSIONS) or an unexpected 404 (NOT_FOUND), check the token's scopes and base access first.

Using the Service Account in Workflows

Add an Airtable block to your workflow. In the credential dropdown, your Airtable service account appears alongside any OAuth credentials. Select it and configure the block as you normally would.

The block calls api.airtable.com using the token — exactly the same requests as the OAuth flow, so every Airtable tool works unchanged, limited to the scopes and bases you granted.

Common Questions

PATs don't expire and don't depend on any user staying logged in or re-consenting. You decide scopes and base access once at creation, and the token is stable until you regenerate or delete it — which is what you want for an automated workflow.

Nothing on the wire — both are the same token format and behave identically in Sim. The difference is ownership: a user PAT dies with the user's base access (or when they leave the org), while a service-account PAT (Enterprise Scale, created in the Admin Panel) belongs to the organization.

The token is missing a scope or, more commonly, base access. Airtable deliberately blurs the two: an unauthorized base can return 403 INVALID_PERMISSIONS or a plain 404 NOT_FOUND. Edit the token at airtable.com/create/tokens and check both the scopes list and the Access section.

No. Airtable PATs remain active indefinitely until they're manually deleted, regenerated, or modified. A user PAT also stops working if its creator loses access to the granted bases or leaves the organization.

Create a new token with the same scopes and base access, update the credential in Sim with the new token, and once it's working, delete the old one. Note that regenerating an existing token invalidates the old value immediately.

Only if you use Airtable triggers in Sim — the trigger creates and manages webhooks on your base. For workflows that only read and write records, you can omit it.