Skip to main content

​
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. All API credentials use the cog_ prefix format. Both token types are used identically in the Authorization header:

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

​
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

​
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