What can my personal access tokens access?

Unlike legacy API keys, which have the same access as your Airtable account, you can limit and configure the access of your personal access tokens. You can do this by selecting the scopes (what endpoints the token can use) and access/resources (which bases and workspaces the token can access) when creating or updating a token. 

Regardless of the scopes and access a user selects for their token, the token will only be able to perform actions that the user creating it is allowed to do. For example, to create a new field in a base via the API, the user must be a Creator collaborator in the base and the token must have the schema.bases:write scope and the base added as a resource. 

For more information about how scopes and access work, see the Authentication developer reference. For more information about configuring your token's access, refer to the personal access tokens guide.

How do I find my API key?

On Jan 18, 2023, we began the deprecating user API keys, completing the deprecation process on Feb 1, 2024, meaning:

• API Keys can no longer access the Airtable API.

• Webhooks created with user API keys will not expire, but can no longer be created.

• All users should migrate to Personal Access Tokens for individual use and OAuth for third-party integrations. To access your PATs:

  • Open the developer hub.

  • Click Personal access tokens under the “Developers” section.

Why might I be seeing the "INVALID_PERMISSIONS_OR_MODEL_NOT_FOUND" error?

Typically, this error type indicates either:

• A permissions-related issue, in which case you’ll want to:

  • Check your PAT scopes

  • Check your permissions level in the base you are referencing

  • See if field and table permissions might also be causing the invalid permissions error.

• An issue with the base referenced, in which case you’ll want to:

  • Double-check that the base id referenced is correct

  • Confirm that the base has not been deleted

More common API troubleshooting information is available here.

I’m not able to access the enterprise scopes. What might be occurring?

The ability to add enterprise. scopes is restricted to Enterprise Scale plans. This feature is not available on Business plans. Upgrading to an Enterprise Scale plan is required to use this functionality.

Do personal access tokens expire?

By default, no. A personal access token has no expiration window of its own and stays active until it is deleted, regenerated, or modified. One exception applies: on enterprise organizations, an admin can set a policy that caps the maximum lifetime of a personal access token. When a token passes that cap, requests using it fail with UNAUTHORIZED - Invalid authentication token. If you're on an enterprise organization and a token that previously worked stops being accepted, ask your admin whether a token lifetime policy is in effect. If no lifetime policy applies and a PAT stops working, the cause is one of the following rather than expiration:

• The token was regenerated, which invalidates the previous token value, so any service still using the old string will fail until updated with the new one.

• The token was deleted, or its scopes or base/workspace access were changed.

If a PAT failure is happening in the environment or application consuming the token, check there, and with that platform's support, if Airtable shows the token as active.

You can review your tokens any time in the developer hub under Personal access tokens.

I have checked my scopes and IDs and still get an INVALID_PERMISSIONS_OR_MODEL_NOT_FOUND error. What else could cause it?

If your scopes, workspace/base IDs, and access all check out and you're on an enterprise organization, the most likely cause is an org-level API restriction set in the admin panel, not your token. When an admin enables "Block API access to organization-owned bases and workspaces" (under Settings → Integrations & development), only users on the API access allowlist can use Personal Access Tokens against organization-owned resources — and requests from anyone not on the allowlist return INVALID_PERMISSIONS_OR_MODEL_NOT_FOUND, even with fully correct scopes and IDs. To resolve it, ask one of your internal Airtable admins to add you (or your service account) to the allowlist for that setting. If the admin needs guidance, point them to Settings – Airtable admin panel. The other documented causes remain worth ruling out: field/table editing permissions and an incorrect or inaccessible base/workspace ID.

Can I use a personal access token to write to a synced table?

No. You can't create or delete records in a synced table, or edit its synced fields, with a personal access token, whatever scopes the token has. A synced table takes its values from its source, so Airtable returns an error such as Your record could not be created because the underlying table is externally synced.

This also applies indirectly: a write to a linked record field fails if it would need to create a new record in a synced table. You can still write to fields you've added to the synced table yourself. Automations can't write to one-way synced tables; with two-way sync, automation actions (but not scripts) can make the edits the sync allows.

Can I limit a personal access token to a single interface?

No, you cannot scope a personal access token to an interface or to an individual view. Token access is granted per base and per workspace, so a token can reach any table or interface in a base it has access to, within the limits of its scopes. If your team works only in interfaces and you need to narrow what a token can reach in the underlying data, use Airtable field and table editing permissions on the tables and fields themselves. Those permissions are honored by API requests, just as they are in the Airtable UI.

Why does my personal access token return "UNAUTHORIZED - Invalid authentication token"?

This error means Airtable did not accept the credential sent in your request's Authorization header. It returns HTTP status 401 with this body:

{"error":{"type":"UNAUTHORIZED","message":"Invalid authentication token"}}

It is a different error from AUTHENTICATION_REQUIRED, which means no credential reached Airtable at all, and from INVALID_PERMISSIONS_OR_MODEL_NOT_FOUND, which means the token was accepted but doesn't have the scopes or resource access the request needs. A token that is rejected here never got as far as a scope or base check, so re-checking scopes and base access won't resolve it.

Work through these causes in order:

• Only the token ID was sent. A complete token is a 17-character ID, a period, then a 64-character secret. The secret is displayed only once, at creation. If you no longer have it, regenerate the token and copy the whole value.

• The secret was truncated or altered between copying and sending. Check for missing characters, added whitespace, or a line break introduced by the tool storing the token.

• The token was deleted, regenerated, or had its access modified after you copied it. Confirm it still appears in the developer hub.

• The token has passed a maximum lifetime set by an admin. On enterprise organizations, an admin policy can cap how long a personal access token stays valid. Once a token is past that cap, every request using it returns this error even though the token still looks correct and still appears in your token list. Ask one of your Airtable admins whether a token lifetime policy applies to your organization.

• The endpoint doesn't accept personal access tokens. A small number of endpoints accept only other credential types, and a personal access token sent to one returns this error regardless of its scopes.

To narrow down which of these applies, repeat the request with response headers shown — for example, curl -i instead of curl -s:

• If the response includes a WWW-Authenticate header containing error="invalid_token", Airtable recognized the value as a personal access token and rejected it during validation. The cause is one of the token-specific items above.

• If that header is absent, the value wasn't recognized as a personal access token at all. Look for a malformed or truncated credential, or an endpoint that doesn't accept personal access tokens.

For error codes beyond authentication, see Airtable API: Common troubleshooting.

Never paste a complete token into a support ticket, community post, or chat conversation. Redact everything after the period, and regenerate any token whose secret you've shared.