> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/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"
```

## 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.

## Creating and managing PATs

Manage your PATs from the **PATs** tab on the **Devin API** settings page.

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 configure the policy 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 can:

* **View all PATs** across the enterprise in the token inventory, including compliance status against the current policy
* **Bulk-revoke** tokens (e.g. after tightening the policy)

Tightening the policy (or disabling PATs) cancels affected pending requests, and the inventory flags existing tokens that no longer comply.

### 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