Access Tokens vs Personal Access Tokens in Dynatrace
If you've spent time working within Dynatrace, you've likely noticed two similar-looking options in the left navigation: Access Tokens and Access Tokens and Personal Access Tokens. They appear almost identical when generated, both start with the same prefix 'dt0c01', and both are used for interacting with the Dynatrace API.
So, what actually sets them apart, and which one should you use?
I recently explored both concepts and here is a practical breakdown.
What is Access Token
An Access Token in Dynatrace is an environment-level API token. This means it belongs to the Dynatrace environment (your tenant), not to any individual user.When you navigate to the Access Tokens page from the left-side menu, Dynatrace clearly indicates this.You will also see Personal Access Tokens (PATs) that have been created and are assigned to specific users.
Refer below snapshot for the understanding. You can also see the Personal Access tokens which have been generated and to whom it got assigned also, Personal Access Tokens labeled as PAT.
You can Manage API access tokens, which provide access to this environment's monitoring and configuration data.
You can manage API access tokens that provide access to this environment's monitoring and configuration data. When creating one, you can give it a name, set an optional expiration date, choose a template or leave it as default, and then select the scopes you need, such as problems.read, oneAgents.write, openTelemetryTrace.ingest, and so on.Once you click 'Generate token', you will be able to copy it into your password manager or a text file.It will never be displayed again.
A useful feature is that Dynatrace provides a ready-made cURL command after generation, which allows you to automate future token creation without searching through documentation. The request body and headers are already filled in for you. As shown in below attached snapshots.
These access tokens are typically used for:
- OneAgent and ActiveGate installations on Servers
- The CI/CD pipelines pushing deployment events
- Integrations with other third-party tools (Jenkins, Ansible, Terraform, ServiceNow)
- Long-running automations that shouldn't be tied to a specific person's account
- Migrating of dynatrace configurations from one dynatrace environment to other through Dynatrace API
Note: To create an Access Token in your Dynatrace environment, you must have Environment Admin permissions. Users without this permission cannot generate Access Tokens.
What is a Personal Access Token (PAT)
A Personal Access Token is tied to the logged-in user. The header on the page clearly states that.The generation form looks similar to the regular Access Token screen, including token name, optional expiration, and scope selection.However, there is an important line at the top of the scope list that indicates the permissions allowed.Before creating a Personal Access Token for yourself or another user, ensure that your Dynatrace environment allows users to generate Personal Access Tokens.You can check this setting in your Dynatrace environment, as shown in the attached snapshot.
Here is the Path: Go to Settings → Environment Segmentation → Access Tokens, as shown in the attached snapshot, and enable the Personal Access Tokens toggle.
Select from scopes available based on your user permissions in your Dynatrace Environment (evaluated dynamically). As shown in below attached snapshot.
A Personal Access Token is user-specific and inherits the Dynatrace permissions of the user who created it. Although someone else can technically use your PAT if you share it, doing so is a security risk as all API actions will be attributed to your account.I would recommend that each user creates and uses their own PAT.
Personal access tokens for [email protected]"
The main difference is that a PAT can never do more than what the user who created it is allowed to do. If your permissions are reduced, your PAT’s capabilities will also decrease accordingly. If your account is deactivated, the PAT will stop working.
Personal Access Token (PATs) are the right choice when:
- You are writing a personal script or building a Postman collection
- You are creating a dashboard integration
- You want the token’s permissions limited to your own access level in Dynatrace
- You want a clear audit trail that shows the user who made the request, rather than “some environment access token”
A Personal Access Token is user-specific and inherits the Dynatrace permissions of the user who created it. Although someone else can technically use your PAT if you share it, doing so is a security risk as all API actions will be attributed to your account.I would recommend that each user creates and uses their own PAT.
Access Tokens provide broader scopes compared to Personal Access Tokens (PATs). PATs are tied to individual users and are meant for personal API access, while Access Tokens are created for applications and integrations, offering broader permissions across more Dynatrace APIs.Although they act as environment-level API tokens, they can also be shared with your team.
Pattern of Access Token and Personal Access Token
Both Tokens are Identically same pattern they starts with dt0c01.
JSON Response Body Output for Personal Access Token and Access Token from Dynatrace API v2
Both Personal Access Tokens and Access Tokens return the same JSON response body format from Dynatrace API. For your reference, I’ve included the cURL (CMD) command execution snapshot below.
Context: I have one only Problem in my Dynatrace for Synthetic Monitoring, Here is the JSON
Context: I have one only Problem in my Dynatrace for Synthetic Monitoring, Here is the JSON
I hope this would be helpful for you, please let me know if you have any doubts on this
