Migrating from API keys to Personal Access Tokens (PATs)

API keys and Personal Access Tokens (PATs) are both used for authentication and authorization. This is your guide on how to migrate from API keys to PATs.

Understanding API keys and PATs

API Keys are primarily used for authenticating requests to the UiPath Orchestrator API. They're generated at the tenant level and offer access to specific Orchestrator resources.

On the other hand, PATs are tailored for authenticating users and applications accessing UiPath services such as Orchestrator, Studio, Document Understanding, and Platform resources. Each PAT is linked with a single user account and access levels can be adjusted based on user needs.

Migration considerations: For migrating from API Keys to PATs, PATs must be defined using application scopes that encompass all Orchestrator scopes (OR.*).

Scope and security

API Keys enable access to resources within a specific Orchestrator tenant and can be restricted via permissions tied to the API key. PATs, conversely, grant users access to the resources within their UiPath organization and can be assigned specific access scopes within UiPath products.

In terms of security, PATs are safer because they link to individual users and can be revoked or replaced at any time.

Migration considerations: Remember that, unlike API keys, PATs have expiration dates. Therefore, these tokens must be regenerated before expiration to ensure uninterrupted access to UiPath services.

Working mechanism

API Keys are primarily utilized for programmatic access to Orchestrator API endpoints.

PATs have more varied applications, including programmatic access to multiple services, but also direct user interactions with the system.

Migration considerations: While API Keys require obtainin a set of tokens from an authentication endpoint, PAT values should be used directly in the API calls as bearer token values in the Authorization header (Authorization: Bearer <PAT value>)