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:

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, 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 instead. Service users provide better audit trails, centralized key management, and RBAC controls. If you’re not sure which to use, see the comparison.

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

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:

• 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 — understand the full auth model
• Teams quick start — get started with service users