Airtable Authentication: API Key & OAuth 2.0 (2026)

Authentication overview

Airtable provides programmatic access to its platform primarily through a REST API, enabling developers to interact with bases, tables, and records. To ensure secure and authorized access, all API requests must be authenticated. Airtable supports two main authentication mechanisms: Personal Access Tokens (API keys) and OAuth 2.0. The choice of method depends on the application's nature, security requirements, and the scope of access needed.

Personal Access Tokens are suitable for server-side applications, scripts, or internal tools where a single developer or system requires direct access to specific bases. These tokens act as bearer tokens, granting the holder the same permissions as the user who generated them. Consequently, they require careful handling and storage to prevent unauthorized access.

OAuth 2.0 is designed for client-side applications, web services, and third-party integrations that need to access Airtable data on behalf of users without requiring the user to share their direct credentials. This method allows users to grant specific permissions (scopes) to an application, enhancing security by limiting what the application can do and providing a mechanism for token revocation. The OAuth 2.0 framework is widely adopted for delegated authorization across various web services, as detailed in the OAuth 2.0 specification.

Supported authentication methods

Airtable primarily supports two distinct authentication methods to cater to different integration scenarios:

1. Personal Access Tokens (API Keys): These are long-lived tokens that provide direct access to your Airtable account's resources, subject to the permissions granted during token creation. They are ideal for server-to-server communication or scripts that operate without direct user interaction. Personal Access Tokens are typically passed in the Authorization header of HTTP requests as a Bearer token.
2. OAuth 2.0: This protocol enables third-party applications to obtain limited access to a user's Airtable account without exposing their credentials. OAuth 2.0 is the recommended method for applications that interact with multiple users or require granular control over permissions. It involves an authorization flow where the user grants consent, and the application receives an access token in return. The Airtable OAuth 2.0 overview provides further details on implementing this flow.

Authentication method comparison

Getting your credentials

The process for obtaining authentication credentials differs based on the chosen method.

Personal Access Tokens

To generate a Personal Access Token:

1. Navigate to the Airtable developer hub and log in to your account.
2. Select 'Personal access tokens' from the navigation.
3. Click 'Create new token'.
4. Provide a descriptive name for your token (e.g., "My Integration Script").
5. Define the scopes for the token. Scopes determine the specific permissions the token will have (e.g., data.records:read, schema.bases:write). It is a best practice to grant only the minimum necessary permissions.
6. Specify the bases the token can access. You can grant access to all current and future bases, specific workspaces, or individual bases. Limiting access to specific bases enhances security.
7. Click 'Create token'.
8. The token will be displayed once. Copy it immediately and store it securely, as it will not be shown again. Treat this token like a password. For detailed instructions on creating and managing tokens, refer to the Airtable Personal Access Tokens guide.

OAuth 2.0

For OAuth 2.0, you need to register your application with Airtable to obtain client credentials:

1. Go to the Airtable developer documentation on OAuth.
2. Follow the steps to register your OAuth application. This typically involves providing an application name, description, and one or more redirect URIs. The redirect URI is where Airtable will send the user back after they authorize your application.
3. Upon registration, you will receive a Client ID and a Client Secret. The Client ID identifies your application, and the Client Secret is used to authenticate your application with Airtable's authorization server.
4. Implement the OAuth 2.0 authorization flow in your application. This involves redirecting users to Airtable's authorization URL, handling the callback to your redirect URI to exchange the authorization code for an access token, and then using the access token to make API requests.

Authenticated request example

Once you have your credentials, you can make authenticated requests to the Airtable API. The examples below demonstrate how to make a simple authenticated request using both Personal Access Tokens and OAuth 2.0 access tokens.

Using a Personal Access Token

When using a Personal Access Token, include it in the Authorization header as a Bearer token:

curl -v -X GET \
  "https://api.airtable.com/v0/appYOUR_BASE_ID/YOUR_TABLE_NAME" \
  -H "Authorization: Bearer YOUR_PERSONAL_ACCESS_TOKEN"

Replace YOUR_BASE_ID with the ID of your Airtable base, YOUR_TABLE_NAME with the name of your table, and YOUR_PERSONAL_ACCESS_TOKEN with your actual Personal Access Token. You can find your base ID and table name in the Airtable API documentation for your base.

Using an OAuth 2.0 Access Token

After completing the OAuth 2.0 flow and obtaining an access token, use it similarly in the Authorization header:

fetch('https://api.airtable.com/v0/appYOUR_BASE_ID/YOUR_TABLE_NAME', {
  headers: {
    'Authorization': 'Bearer YOUR_OAUTH_ACCESS_TOKEN'
  }
})
.then(response => response.json())
.then(data => console.log(data))
.catch(error => console.error('Error:', error));

Again, replace YOUR_BASE_ID, YOUR_TABLE_NAME, and YOUR_OAUTH_ACCESS_TOKEN with your specific values. The Airtable API introduction provides further guidance on API endpoints and parameters.

Security best practices

Adhering to security best practices is crucial when handling Airtable authentication credentials to prevent unauthorized access and data breaches.

• Store credentials securely: Never hardcode API keys or client secrets directly into your application code. Use environment variables, secure configuration files, or dedicated secret management services (e.g., AWS Secrets Manager, Google Secret Manager, Azure Key Vault). The AWS Secrets Manager introduction provides an example of a dedicated secret management service.
• Use the principle of least privilege: When creating Personal Access Tokens or defining OAuth scopes, grant only the minimum necessary permissions required for your application to function. Avoid granting broad access (e.g., write access to all bases) if only read access to specific bases is needed.
• Rotate credentials regularly: Periodically rotate your Personal Access Tokens. Implement a process to generate new tokens and deprecate old ones. For OAuth, ensure refresh tokens are managed securely and used to obtain new access tokens when old ones expire.
• Encrypt data in transit: Always use HTTPS for all API communications to ensure that authentication tokens and data are encrypted during transit, protecting against eavesdropping and man-in-the-middle attacks. Airtable's API inherently uses HTTPS.
• Monitor API usage: Keep an eye on your API usage logs for any unusual activity that might indicate a compromised token or unauthorized access attempt.
• Implement rate limiting and error handling: While Airtable handles its own rate limiting, robust error handling in your application can help identify and respond to authentication failures or potential abuse attempts.
• Revoke compromised tokens immediately: If you suspect a Personal Access Token or OAuth access token has been compromised, revoke it immediately through your Airtable account settings or the OAuth management interface.
• Educate developers: Ensure all developers working with Airtable API integrations understand the importance of secure credential handling and API best practices.