How to create a read-only Airtable personal access token for backups

Airtable's personal access tokens replaced API keys and, unlike the old keys, they can be limited to exactly what a tool needs. For a backup that means read-only access, and ideally to a single base. This guide takes about a minute to follow.

Why read-only matters

A backup tool only needs to read. Any token you give it that can also write is a risk with no upside: a bug, a compromised laptop, or a leaked config file could change or delete data in your base. Two read scopes are all a complete export needs, and Airtable lets you grant exactly those and nothing else.

Step by step

1. Go to airtable.com/create/tokens. You need to be logged in as a user who can access the base.
2. Click Create new token.
3. Give it a name that says what it is for, for example "Tablevault backups". Names are for you; the tool never sees them.
4. Under Access, click Add a base and choose only the base you want to back up. You can add more bases later, or create a separate token per base. Avoid granting access to all bases in a workspace unless you intend to back them all up.
5. Under Scopes, add exactly two:
   • schema.bases:read, which lets the tool list your bases and read each base's tables and fields, including which table a linked-record field points to.
   • data.records:read, which lets it read records. Do not add any scope ending in :write, and do not add user.email:read or anything else. The tool does not need them.
6. Click Create token. Airtable shows the token once. It starts with pat and is around 80 characters long. Copy it now; if you close the dialog you will need to create a new one.

Paste it into the tool, and you are done.

Managing tokens afterwards

The same page lists every token you have created, with its scopes and bases. From there you can:

• Revoke a token instantly. The tool using it will start receiving authentication errors on its next request. This is the right response if you ever suspect a token has leaked.
• Regenerate a token, which keeps the scopes and access but issues a new secret.
• Edit access to add or remove bases.

A token belongs to your user account. If you leave the workspace, or your access to the base is removed, the token stops working for that base even though it still exists. For a backup that should outlive any one person's account, create the token from a shared or service account that will remain.

What a token can and cannot reveal

With these two scopes a token can read every record in the granted bases, including every field and every attachment. Treat it like a password to that data. It cannot read bases you did not grant, cannot see other users' details, cannot change anything, and cannot access your Airtable account settings.

How Tablevault uses it

Tablevault's free export validates the token against Airtable, confirms it has the two read scopes and nothing more, and lists the bases it can see so you can pick one. The token is stored encrypted only for as long as the export runs, and is deleted afterwards. You can revoke it from Airtable at any point, before or after, with no effect on the zip you received. If you later choose scheduled backups, you create a fresh token for that.