Try it free

Manage your Azure connections via API

  • Latest Dynatrace
  • How-to guide
  • Published Sep 09, 2026

The Dynatrace REST API enables you to create, update, retrieve, and delete both Azure connections and their associated monitoring configurations.

An Azure connection is the foundational link between Dynatrace and your Azure environment, using a dedicated Microsoft Entra ID service principal for authentication and authorization. Each connection is paired one-to-one with a monitoring configuration—the blueprint that governs all monitoring behavior for that connection, such as which Azure services to poll for metrics and which regions to target.

Once an Azure connection is in place, you can use the REST API to fully manage its linked monitoring configuration.

To learn how to create an Azure connection via the REST API, see Create an Azure connection via API.

Prerequisites

The commands on this page require a platform token with the Settings and Extensions scopes, as described in the Dynatrace prerequisites for creating an Azure connection.

Windows

The shell commands on this page use \ for line continuation (bash/zsh). On Windows, replace \ with a backtick (`) in PowerShell, or ^ in command prompt.

List monitoring configurations

Retrieve all Azure monitoring configurations in your environment to find the objectId of the one you want to modify or delete.

  1. Prepare the request.

    curl -X 'GET' \
    '<YOUR_ENVIRONMENT_URL>/platform/extensions/v2/extensions/com.dynatrace.extension.da-azure/monitoring-configurations' \
    -H 'accept: application/json' \
    -H 'Authorization: Bearer <YOUR_BEARER_TOKEN>'
  2. Replace the following placeholders with your values and send the request:

    • <YOUR_ENVIRONMENT_URL>: URL of your Dynatrace environment (for example, https://abc12345.apps.dynatrace.com)
    • <YOUR_BEARER_TOKEN>: Settings platform token
  3. The response lists each configuration with its objectId:

    {
    "items": [
    {
    "objectId": "e4bf05f3-d829-3689-8dd4-a9d2aeab0607",
    "scope": "integration-azure",
    "value": {
    "enabled": true,
    "description": "production-monitoring"
    }
    }
    ],
    "totalCount": 1
    }
  4. The objectId is the monitoring configuration unique identifier and is used across all GET/PUT/DELETE API calls. Save the objectId of the configuration you want to manage.

You can also find this value in Settings Settings as the connection's Monitoring Configuration ID property on the Overview tab.

Modify an existing monitoring configuration

Modifying a monitoring configuration is an atomic API call and is effective immediately.

The PUT endpoint requires the full configuration object—partial payloads are not supported. This is why the workflow below always starts with a GET: you modify only the fields you need on top of the full object returned, then submit the whole thing back.

  1. Retrieve the existing configuration using a GET request.

    curl -X 'GET' \
    '<YOUR_ENVIRONMENT_URL>/platform/extensions/v2/extensions/com.dynatrace.extension.da-azure/monitoring-configurations/<MONITORING_CONFIG_ID>' \
    -H 'accept: application/json' \
    -H 'Authorization: Bearer <YOUR_BEARER_TOKEN>'

    Replace the following placeholders with your values:

    • <YOUR_BEARER_TOKEN>: Settings platform token
    • <YOUR_ENVIRONMENT_URL>: URL of your Dynatrace environment (for example, https://abc12345.apps.dynatrace.com)
    • <MONITORING_CONFIG_ID>: ID of the monitoring configuration you want to modify
  2. Modify the retrieved configuration JSON as needed (for example, add/remove monitored regions, enable/disable feature sets, update filtering rules).

    For the available filtering and enrichment options, see Advanced configuration options.

  3. Update the configuration using a PUT request.

    Replace the following placeholders with your values:

    • <YOUR_BEARER_TOKEN>: Settings platform token
    • <YOUR_ENVIRONMENT_URL>: URL of your Dynatrace environment (for example, https://abc12345.apps.dynatrace.com)
    • <MONITORING_CONFIG_ID>: ID of the monitoring configuration you want to modify
    • <MODIFIED_CONFIG_PAYLOAD>: Modified configuration JSON from step 2
    curl -X 'PUT' \
    '<YOUR_ENVIRONMENT_URL>/platform/extensions/v2/extensions/com.dynatrace.extension.da-azure/monitoring-configurations/<MONITORING_CONFIG_ID>' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: Bearer <YOUR_BEARER_TOKEN>' \
    -d '<MODIFIED_CONFIG_PAYLOAD>'

    A successful request responds with the updated monitoring configuration ID (in objectId field):

    {
    "objectId": "e4bf05f3-d829-3689-8dd4-a9d2aeab0607",
    "code": 200
    }

Delete an existing monitoring configuration

This action is immediate and irreversible. Deleting a monitoring configuration causes telemetry polling downtime and automatically removes its mapped Azure connection.

We recommend thorough testing of any automation scripts before running them in production—particularly scripts that iterate over and delete multiple monitoring configurations and their associated Azure connections.

To delete an existing monitoring configuration

  1. Replace the following placeholders with your values:

    • <YOUR_BEARER_TOKEN>: Settings platform token
    • <YOUR_ENVIRONMENT_URL>: URL of your Dynatrace environment (for example, https://abc12345.apps.dynatrace.com)
    • <MONITORING_CONFIG_ID>: ID of the monitoring configuration you want to delete
    curl -X 'DELETE' \
    '<YOUR_ENVIRONMENT_URL>/platform/extensions/v2/extensions/com.dynatrace.extension.da-azure/monitoring-configurations/<MONITORING_CONFIG_ID>' \
    -H 'accept: application/json' \
    -H 'Authorization: Bearer <YOUR_BEARER_TOKEN>'
  2. A successful request responds with 204 No Content status, indicating that the configuration was deleted successfully.

A deleted monitoring configuration does not delete any supporting Azure resources deployed in your environment (for example, logs infrastructure).

You must delete these manually to avoid lingering resources that incur Azure and Dynatrace costs.

Roll over a client secret

This procedure applies to connections that use client secret authentication. If you want to eliminate ongoing secret rotation, consider migrating to federated identity credentials instead.

Update the connection in Dynatrace before the existing secret expires to avoid a monitoring gap.

If you didn't save <AZURE_CONNECTION_ID> when you created the connection, retrieve it with:

curl -X 'GET' \
'<YOUR_ENVIRONMENT_URL>/platform/classic/environment-api/v2/settings/objects?schemaIds=builtin:hyperscaler-authentication.connections.azure' \
-H 'accept: application/json' \
-H 'Authorization: Bearer <YOUR_BEARER_TOKEN>'

The objectId field in the response is your <AZURE_CONNECTION_ID>.

  1. Replace the following placeholders with your values:

    • <APPLICATION_ID>: Application (client) ID of the Azure service principal
    • <CONNECTION_NAME>: Name of the existing Dynatrace Azure connection
    • <TENANT_ID>: Microsoft Entra ID tenant (directory) ID
    • <CLIENT_ID>: Application (client) ID of the service principal
    • <NEW_CLIENT_SECRET>: New client secret generated in step 3: save it immediately as it can't be retrieved later
    • <OLD_KEY_ID>: The keyId of the old credential captured in step 2
    • <YOUR_BEARER_TOKEN>: Settings platform token
    • <YOUR_ENVIRONMENT_URL>: URL of your Dynatrace environment (for example, https://abc12345.apps.dynatrace.com)
    • <AZURE_CONNECTION_ID>: The objectId of the Azure connection, returned when it was created
  2. List the current credentials for your service principal to capture the keyId of the existing secret.

    az ad app credential list --id "<APPLICATION_ID>" --output table

    Note the keyId value. You'll need it in step 6 to remove the old secret.

  3. Generate a new client secret. The --append flag adds the new credential without invalidating the existing one, so Dynatrace monitoring continues uninterrupted during the rollover.

    az ad app credential reset \
    --id "<APPLICATION_ID>" \
    --append \
    --display-name "Dynatrace rollover $(date +%Y-%m-%d)" \
    --query password \
    --output tsv

    The command outputs the new secret. Save this value as <NEW_CLIENT_SECRET>—it can't be retrieved again after this point.

  4. Prepare the update payload with the new secret value.

    {
    "value": {
    "clientSecret": {
    "directoryId": "<TENANT_ID>",
    "applicationId": "<CLIENT_ID>",
    "clientSecret": "<NEW_CLIENT_SECRET>",
    "consumers": ["SVC:com.dynatrace.da"]
    },
    "name": "<CONNECTION_NAME>",
    "type": "clientSecret"
    }
    }
  5. Send the PUT request to update the connection.

    curl -X 'PUT' \
    '<YOUR_ENVIRONMENT_URL>/platform/classic/environment-api/v2/settings/objects/<AZURE_CONNECTION_ID>?validateOnly=false' \
    -H 'accept: application/json' \
    -H 'Content-Type: application/json' \
    -H 'Authorization: Bearer <YOUR_BEARER_TOKEN>' \
    -d '<REQUEST_PAYLOAD>'

    A successful request responds with the updated Azure connection ID (in objectId field):

    {
    "code": 200,
    "objectId": "vu9U3hXa3q0AAAABADRidWlsdGlu..."
    }
  6. Once the connection is Healthy in Dynatrace, remove the old secret from Azure.

    az ad app credential delete \
    --id "<APPLICATION_ID>" \
    --key-id "<OLD_KEY_ID>"

Troubleshooting

Monitoring configuration curl request hangs with no response

Some environments return no HTTP response to curl requests against the /platform/extensions/v2/ endpoints, causing the command to hang until a timeout.

Solution: Add --http2 to force HTTP/2:

curl --http2 -X 'GET' \
'<YOUR_ENVIRONMENT_URL>/platform/extensions/v2/extensions/com.dynatrace.extension.da-azure/monitoring-configurations' \
...

Verify your curl build includes HTTP/2 support by running curl --version—the output should include HTTP2 in the features list.

API call fails with a 4xx error

If the API call fails, validate that:

  • You have the required service user permissions and platform token scopes to read from and write to the Monitoring Configuration (Extensions) API.
  • Your settings platform token is valid and assigned to the correct Dynatrace environment/account.
  • The monitoring configuration exists and the objectId is correct.
Related tags
Infrastructure Observability