Skip to main content

Personal Access Token (PAT)

A Personal Access Token (PAT) is an access token created and managed by an individual user for their own programmatic API access. PATs let you authenticate API requests without an interactive browser login flow.

This is different from a Service Account Token (SAT), which is admin-created, centrally managed, and supports user impersonation for server-side automation.

Where PATs live in the product​

PATs are managed in Twin Settings → Use Digital Twin Anywhere, in the Personal Access Token section. Each user creates and revokes their own tokens — no admin involvement is required.

How PAT authentication works at request time​

When a client calls our APIs using a PAT:

  • The client sends the PAT as a bearer token in the Authorization header.
  • Our backend verifies the token before servicing the request.
  • The request is authenticated as the user who created the token.
  • Requests are subject to scope checks, similar to SATs.
Authorization: Bearer <personal_access_token>

Creating and managing PATs​

From the Personal Access Token section in Twin Settings:

  • Create a named token with an expiry period (default 30 days).
  • Each user can have up to 2 active tokens at a time.
  • Revoke tokens when they are no longer needed.

You will get an email notification when your token is about to expire. Please rotate the token in a timely fashion to prevent disruption.

When PATs are the right tool​

PATs are especially useful when:

  • You are setting up a personal integration for MCP clients that do not support OAuth, or for scripts and agent frameworks that need a static credential.
  • You need user-owned automation where central admin provisioning is unnecessary.

For MCP clients that support OAuth (for example Claude or ChatGPT), prefer the browser consent flow described in MCP Reference — no PAT is required. If you need admin-managed automation that acts on behalf of multiple users, see Service Account Token (SAT) instead.

Security best practices​

  • Store tokens securely and never commit them to source control.
  • Use the minimum required scopes when creating a token.
  • Revoke tokens promptly when they are no longer in use.