# Authentication

## Basics

Airtable's API uses token-based authentication, allowing users to authenticate API requests by inputting their tokens
into the HTTP authorization bearer token header.

Example:

```
curl https://api.airtable.com/v0/YOUR_BASE_ID/YOUR_TABLE_ID_OR_NAME -H \
"Authorization: Bearer YOUR_TOKEN"
```

All API requests must be authenticated and made through HTTPS.

Passing personal access tokens and OAuth access tokens via the legacy `api_key` URL parameter is not supported.

## Types of token

> As of February 1st 2024, the deprecation period for Airtable API keys has ended. Users of Airtable API keys must
> migrate to the new authentication methods to continue using Airtable's API. See [this article](https://support.airtable.com/docs/airtable-api-key-deprecation-notice)
> for more details.

We currently support using personal access tokens and OAuth access tokens during the authentication process.

[Personal access tokens](/guides/personal-access-tokens) are for personal development, like building an integration for
yourself, your client, or your company. They can be created and managed at [/create/tokens](/../../create/tokens) or
from the enterprise admin panel for [service accounts](https://support.airtable.com/docs/service-accounts-overview). Personal access tokens act as your user account, and should not
be shared with third-party services or integrations.

[OAuth access tokens](/guides/oauth-integrations) are recommended for building an integration where other users grant your
service access to Airtable’s API on their behalf. In this case, your integration is a third-party service with respect to Airtable.
After registering your integration with Airtable at [/create/oauth](/../../create/oauth), tokens are available
via the [OAuth grant flow](https://oauth.net/2/).

Any integrations that allow other users to grant access to Airtable should use OAuth.

## Scopes and resources/access

Personal access and Oauth tokens serve as the account of the user who grants access, with the following limitations:

-   [Scopes](/api/scopes): What actions the token can perform.
-   Resources/access: What bases and workspace the token can access. Tokens can be granted access to individual—or all—bases/workspaces. These can be listed using the [list bases](/api/list-bases) endpoint.

For example, to update a record in a base via API, the user who granted the token must have editor access to the base.
Additionally, the token must have both the correct scope (`data.records:write`) and the base added to it as a resource.

For personal access tokens, scopes and resources/access are individually configured from [/create/tokens](/../../create/tokens).
And for OAuth access tokens, developers choose the requested scopes from [/create/oauth](/../../create/oauth),
while end-users decide what resources to grant access to.