Overview

Personal Access Tokens (PATs) are a credential type that authenticates Datadog API calls. Unlike application keys, PATs do not need to be paired with an API key. They are short-lived and scoped by default, giving you tighter control over what each token can access and how long it remains valid.

With PATs, you can:

• Authenticate API calls with a single credential.
• Enforce the principle of least privilege by selecting only the scopes your workflow needs.
• Limit the blast radius of leaked credentials through mandatory time-to-live (TTL) values. Expired tokens are automatically revoked, so inactive credentials do not persist indefinitely.
• Separate concerns by reserving API keys for telemetry submission (Agent, logs, metrics) and use PATs for all other web API calls.

PATs compared to other credential types

For Service Access Tokens, see Service Access Tokens.

Prerequisites

• A Datadog user account with the user_app_keys permission
• The org_app_keys_write permission if you want to manage PATs for other users in the organization

Create a Personal Access Token

1. Navigate to Personal Settings > Access Tokens.
2. Click
   • New Access Token
   .
3. Enter a Name for the token.
4. Select an Expiration Date. The minimum expiration is 24 hours and the maximum is one year from creation.
5. Click Select Scopes to choose the scopes that define what this token can access. At least one scope is required. Grant only the permissions your workflow requires, then click Save.

Use a Personal Access Token

PATs support two authentication methods.

Authorization header (recommended)

Pass the PAT as a Bearer token in the Authorization header. This method does not require an API key:

curl -X GET "https://api.datadoghq.com/api/v2/users" \
  -H "Authorization: Bearer <YOUR_PAT>"

Application key header

Pass the PAT in the dd-application-key header. This is useful for migrating existing integrations that already use the application key header format:

curl -X GET "https://api.datadoghq.com/api/v2/users" \
  -H "dd-application-key: <YOUR_PAT>"

Note: When a valid PAT is provided in the dd-application-key header, Datadog authenticates with the PAT only. The dd-api-key header is optional and its value is not evaluated.

Restrictions on PAT-authenticated API calls

To prevent privilege escalation, Datadog restricts what an API call authenticated with a PAT can do. These restrictions apply regardless of the API client making the call:

• Application keys: A PAT cannot create or update application keys. Revoking application keys is allowed.
• Scopes on new tokens: A PAT can create or update a PAT or a SAT only if the new token’s scopes are a subset of its own scopes.
• Time-to-live (TTL) on new tokens: A PAT cannot create a PAT or a SAT with a TTL that extends beyond its own expiration.

A call that violates one of these restrictions returns a 403 Forbidden response.

Manage Personal Access Tokens

View your tokens

Navigate to Personal Settings > Access Tokens to see all PATs associated with your account, including their names, scopes, expiration dates, and last usage information.

After creating a token, a details panel displays the token secret, name, Token ID, owner, scopes, and expiration date. From this panel, you can also edit or revoke the token.

Manage tokens as an administrator

Organization administrators with the org_app_keys_read and org_app_keys_write permissions can view and manage PATs for all users in the organization from Organization Settings > Access Tokens.

Revoke a token

1. Navigate to Personal Settings > Access Tokens, or Organization Settings > Access Tokens for administrators.
2. Mouse over the token you want to revoke and click the Revoke Token icon.

Revoked tokens can no longer authenticate API calls. Revocation takes effect within seconds.

Edit a token

You can update the name and scopes of an existing PAT. You cannot modify the TTL after creation. To change the TTL, revoke the existing token and create a token with the desired configuration.

Token format

PATs use an identifiable format that supports secret scanning and key management:

ddpat_<ALIAS>_<SECRET><CHECKSUM>

The identifiable prefix and checksum enable automated detection by secret scanning services, including GitHub secret scanning, Sensitive Data Scanner, and GitGuardian.

Permissions

PATs use the same permissions as application keys:

For more information about permissions, see Role Based Access Control.

Audit Trail

If Audit Trail is enabled for your organization, Audit Trail records all PAT creation, usage, and revocation events. Audit Trail captures the authentication method and token metadata for each API call made with a PAT, giving administrators visibility into credential usage across the organization.

To review PAT activity, navigate to Security > Compliance > Audit Trail and filter by the Personal Access Token authentication method.

API reference

Manage PATs programmatically through the Datadog API:

The GET /api/v2/personal_access_tokens endpoint returns both PATs and SATs in a single call. To manage SATs, see Service Access Tokens.

For the full API reference, see Key Management.

Key propagation delay

PATs follow an eventual consistency model. After creation or revocation, changes may take a few seconds to propagate across all Datadog systems. Do not use a token immediately after creation in critical workflows. Implement a retry strategy with short exponential backoff to handle transient errors during the propagation window.

Further reading

お役に立つドキュメント、リンクや記事:

Modernize Datadog API authentication with scoped credentialsBLOG