Monaco API support and access permission handling

  • Latest Dynatrace
  • Reference
  • 1-min read
  • Published Jul 22, 2025

Dynatrace offers different options to authenticate API calls. Dynatrace Monaco supports the following authentication options:

  • Platform tokens
  • OAuth clients

For details about Dynatrace Identity and Access Management (including platform tokens, API tokens, and OAuth clients), see Tokens and OAuth clients.

Create a platform token for the Dynatrace Moncao CLI

To create a platform token, follow the steps described in Create a platform token for the Dynatrace Monaco CLI. Each available type of platform configuration requires specific OAuth scopes.

Create an OAuth client for the Dynatrace Monaco CLI

To create an OAuth client, follow the steps described in Create an OAuth2 client.

Each available type of platform configuration requires specific OAuth scopes.

To use the automation:workflows:admin scope, you need to do the following before creating the OAuth client.

  1. Create a custom policy granting that scope.
  2. Bind a group to it.
  3. Assign your user to that group.

For detailed information on managing policies, see IAM policy reference.

To manage OpenPipeline configurations, ensure that the user belongs to a group with the policy Data Processing and Storage assigned to it. Do this before creating the OAuth client.

In addition to the scopes available to the OAuth client, permissions can be further limited via policies applied to the user's groups.

When working with a service user, ensure the service user's permissions match the OAuth scopes for all environments. For details on how permissions can be controlled, see Working with policies.

To use your OAuth client:

  1. Follow the instructions for your operating system or CI/CD tool on how to make the client ID and secret available as environment variables.
  2. Reference the environment variables you have created in the OAuth section of your manifest file
  3. Dynatrace Monaco CLI will request OAuth access tokens using your client credentials to make authenticated API calls.

Create an API access token (classic)

Access tokens are used to authenticate Dynatrace classic API calls. For more information about how to use a Dynatrace API token, see Dynatrace API - Tokens and authentication.

Define environment variables for your authentication client and secret.

To use your access token:

  1. Follow the instructions for your operating system or CI/CD tool on how to make the client ID and secret available as environment variables.
  2. Reference the environment variables you have created in the OAuth section of your manifest file
  3. Dynatrace Monaco CLI will request OAuth access tokens using your client credentials to make authenticated API calls.

API coverage

Dynatrace Monaco supports the following configuration types:

  • Settings 2.0
  • Configuration APIs
  • Platform APIs

The specific configuration types are defined in the Monaco configuration YAML file.

Settings 2.0

Settings 2.0 resources require a classic Dynatrace API access token or OAuth credentials.

The Dynatrace Monaco CLI provides general support for any Settings 2.0 schema available in your environment. For information about schemas, see Settings 2.0 - Available schemas.

For latest Dynatrace, you will need the following OAuth scopes.

PurposeScope
Manage Settings 2.0 objects and its all-users permissionsettings:objects:read, settings:objects:write
View Settings 2.0 schemassettings:schemas:read

For classic Dynatrace, you will need the following OAuth scopes.

PurposeScope
Manage Settings 2.0 objects and its all-users permissionsettings.read, settings.write

Supported platform API types

The Dynatrace platform provides a collection of platform services, each with a specific area of responsibility. OAuth credentials are required to target platform APIs.

The Dynatrace Monaco CLI provides support for Dynatrace platform API types as described in the table below.

Platform serviceConfiguration typeEndpointOAuth client permissionsMonaco CLI version

Automation

business-calendars

/platform/automation/v1/business-calendars

automation:calendars:read, automation:calendars:write

2.6.0+

scheduling-rules

/platform/automation/v1/scheduling-rules

automation:rules:read, automation:rules:write

2.6.0+

workflows

/platform/automation/v1/workflow

automation:workflows:read, automation:workflows:write

2.6.0+

Grail–-storage management

buckets

/platform/storage/management/v1/bucket-definitions

storage:bucket-definitions:read, storage:bucket-definitions:write, storage:bucket-definitions:delete

2.9.0+

Documents (Dashboards, Notebooks, Launchpads)

documents

/platform/document/v1/documents

document:documents:write, document:documents:read, document:documents:delete, document:trash.documents:delete

2.15.0+

OpenPipeline

openpipelines

/platform/openpipeline/v1/configurations

openpipeline:configurations:read, openpipeline:configurations:write

2.15.0+

Grail

segment

/platform/storage/filter-segments/v1/filter-segments

storage:filter-segments:read, storage:filter-segments:write, storage:filter-segments:delete, storage:filter-segments:admin

2.19.0+

SLOs

slo-v2

/platform/slo/v1/slos

slo:slos:read, slo:slos:write, slo:objective-templates:read

2.22.0+

Account Management permissions

To manage account resources, such as user management or policy handling, OAuth credentials require the following permissions:

  • account-idm-read
  • account-idm-write
  • account-env-read
  • account-env-write
  • iam-policies-management
  • iam:policies:write
  • iam:policies:read
  • iam:bindings:write
  • iam:bindings:read
Related tags
Software Delivery