> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Personal Access Tokens

> Authenticate as yourself for programmatic API access

## Overview

Personal Access Tokens (PATs) allow human users to authenticate programmatically under their own identity. Unlike service user API keys (which authenticate as a non-human service user), a PAT authenticates as **you** — the human user who created the token.

| Token type | Authenticates as | Identity | Permissions |
| - | - | - | - |
| **Service User API Key** | Service User (non-human) | The service user's identity | The service user's assigned role |
| **Personal Access Token** | User (human) | Your user identity | Your permissions and org memberships |

All API credentials use the `cog_` prefix format. Both token types are used identically in the `Authorization` header:

```bash theme={null}
curl "https://api.devin.ai/v3/organizations/$DEVIN_ORG_ID/sessions" \
  -H "Authorization: Bearer $YOUR_PAT"
```

## Scope and permissions

A PAT belongs to you, within your account (your Teams account or your enterprise). It is not tied to one organization, and there is no such thing as an "organization PAT" or an "enterprise PAT". This is different from [service users](/api-reference/authentication#service-user-scopes), which are created at either the organization or enterprise level.

| | Personal access token |
| - | - |
| **Belongs to** | Your user, within one account |
| **Where you manage it** | The **PATs** tab on **Settings > Devin API**, in any organization or in enterprise settings |
| **What it can call** | `/v3/organizations/{org_id}/*` for every organization you have access to; `/v3/enterprise/*` if you have the matching enterprise permissions |

Each request picks the organization. Organization endpoints name it in the URL path (`/v3/organizations/{org_id}/...`), and the request is authorized by your access and role in that organization. A request for an organization you can't access fails.

The token has the same permissions as your user. Anything you can do in the web app, you can do with your PAT, and nothing more.

To create, rotate, or revoke PATs you need **Manage API keys** in the organization whose settings you are viewing, or **Manage account API keys** at the account level. This permission controls who can manage tokens; it does not change what a token can do.

Enterprise accounts also have an internal organization that only stores enterprise-wide settings. It is not a workspace. PAT requests that target it are rejected with `403`, so always use a child organization ID.

## When to use PATs

PATs are designed for scenarios where you need programmatic API access **as yourself**:

* **Personal scripts and tooling** — automate your own workflows without a shared service user
* **Local development** — test API integrations using your own account
* **Short-lived automation** — one-off scripts that should be attributed to you

For production integrations, CI/CD pipelines, and shared automation, use [service user API keys](/api-reference/authentication#service-users-recommended-for-automation) instead. Service users provide better audit trails, centralized key management, and RBAC controls. If you're not sure which to use, see the [comparison](/api-reference/authentication#personal-access-token-or-service-user).

## Creating and managing PATs

Manage your PATs from the **PATs** tab on the **Devin API** settings page, in any organization or in enterprise settings. The tab shows the same tokens either way (see [Scope and permissions](#scope-and-permissions)).

1. **Create a PAT** — give it a name and an expiration date. The token starts with `cog_` and is shown only once at creation time.
2. **Use the token** in the `Authorization` header — exactly like a service user API key. Every API call authenticates as your user account: your permissions, org memberships, and audit trail apply.
3. **Rotate a PAT** — generate a new secret for an existing token without changing its name; the old secret stops working immediately.
4. **Revoke a PAT** — invalidate the token at any time.

PATs are also accepted by real-time endpoints such as the ACP live WebSocket, so tools like the Devin CLI and desktop clients can authenticate with a PAT.

## Enterprise governance

For enterprise accounts, PAT availability is controlled by an enterprise-wide **PAT policy** that applies across all of the enterprise's organizations. Enterprise admins with **Manage enterprise settings** configure the policy (and handle approval requests) from the **PAT policies** tab on the enterprise **Devin API** settings page.

### Policy modes

| Mode | Behavior |
| - | - |
| **Disabled** (default) | Members cannot create or use PATs |
| **Approval required** | Members submit a PAT request; an enterprise admin must approve it before the token can be created |
| **Self serve** | Members can create PATs directly, subject to the expiration policy |

### Expiration policy

When PATs are enabled for an enterprise, every PAT **must have an expiration date**, capped by the policy's maximum lifetime (**365 days** by default; admins can configure a shorter cap). Non-enterprise (Teams) accounts may create non-expiring PATs.

### Approval workflow

Under **Approval required**:

1. A member requests a PAT from the PATs tab (name + expiration).
2. Enterprise admins see the request in the **Approval queue** and approve or deny it.
3. Once approved, the member completes the request to mint the token (shown once).
4. Pending requests lapse automatically after **7 days** if not acted on.

Requesters and admins are notified by email at each step of the token lifecycle (requested, approved, denied, revoked).

### Token inventory and revocation

Enterprise admins with **Manage account API keys** can open the **PAT inventory** view on the **PAT policies** tab to:

* **View PATs** across the enterprise, with each token's name, owner, creation date, expiration date, and status (**Active**, **Revoked**, or **Expired**). Filter by status or search by name or owner.
* **Revoke** an active token from its row. The inventory revokes one token at a time.

The inventory does not show whether a token complies with the current policy. Compliance is checked when you change the policy: if a new mode or a shorter maximum expiration would make existing tokens noncompliant, a confirmation dialog lists the affected tokens and their violations before the change is applied. Admins without **Manage account API keys** see only the number of affected tokens. Confirming revokes those tokens and cancels their owners' pending requests. Switching the policy to **Disabled** revokes every active PAT and cancels all pending requests.

### Automatic revocation

A user's PATs are automatically revoked when they lose membership in the account — including removals via SCIM deprovisioning or IdP group changes.

## Security considerations

* Treat PATs with the same care as passwords — they provide full access to your account
* Store PATs in environment variables or secret managers, never in source code
* Set the shortest expiration that works for your use case
* Revoke PATs immediately if compromised
* Prefer service user API keys for any shared or production automation

## Next steps

* [Authentication overview](/api-reference/authentication) — understand the full auth model
* [Teams quick start](/api-reference/getting-started/teams-quickstart) — get started with service users


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.