Datadog API Client for Python

Warnings

• gotcha Always use `DD_API_KEY` and `DD_APP_KEY` environment variables for authentication to avoid exposing credentials in code. While in-code configuration is possible, it is less secure.
  Fix: Store `DD_API_KEY` and `DD_APP_KEY` as environment variables. The client automatically picks them up, or you can explicitly set `configuration.api_key` from `os.environ.get()`.
• deprecated Many V1 API endpoints are deprecated and have V2 equivalents. While V1 might still work, it's recommended to use V2 endpoints for new development and migrate existing code where possible to ensure access to the latest features and avoid future breaking changes.
  Fix: Consult the official Datadog API documentation to identify the V2 equivalent for your desired functionality and update your imports and API calls accordingly (e.g., `from datadog_api_client.v2.api.metrics_api import MetricsApi`).
• gotcha The default Datadog API site is `datadoghq.com` (US). If your Datadog account is hosted in a different region (e.g., EU, US1-FED), you must explicitly configure the client to use the correct regional endpoint. Otherwise, API calls will fail or target the wrong Datadog instance.
  Fix: Set the `DD_SITE` environment variable (e.g., `DD_SITE=datadoghq.eu`) or configure it in code: `configuration.server_variables["site"] = "datadoghq.eu"`.
• breaking The client includes access to 'unstable' API endpoints that are subject to breaking changes without major version bumps. These endpoints require an explicit opt-in configuration step.
  Fix: Enable unstable operations with `configuration.unstable_operations["<OperationName>"] = True`. Be aware that code using these endpoints may break in future minor releases.
• gotcha Datadog APIs are subject to rate limits. Failing to implement retry and backoff logic can lead to API call failures (e.g., HTTP 429 Too Many Requests) and degraded application performance.
  Fix: Implement robust retry mechanisms with exponential backoff. The library can be configured with a custom retry policy using `urllib3.util.Retry`.
• gotcha There are two distinct Python libraries for Datadog: `datadog` (the older client, `pip install datadog`) and `datadog-api-client` (the newer, generated client, `pip install datadog-api-client`). Ensure you are importing and using the correct library for your needs, as they have different interfaces and capabilities. `datadog-api-client` supports all public Datadog API endpoints.
  Fix: For comprehensive API coverage and the latest features, use `datadog-api-client`. If you are migrating, be aware of the different import paths and API call patterns.
• gotcha There have been reports of memory not being released after API calls, potentially leading to increased memory usage in long-running applications.
  Fix: Ensure `ApiClient` is used as a context manager (`with ApiClient(...) as api_client:`), which handles connection closing. For persistent issues, consider explicitly calling garbage collection (`gc.collect()`) after intensive API operations or analyzing memory usage patterns.

Install

• pip install datadog-api-client Standard Installation
• pip install datadog-api-client[async] Asynchronous Support

Imports

• ApiClient

  from datadog_api_client import ApiClient

  Core class for making API requests, typically used with a Configuration object.
• Configuration

  from datadog_api_client import Configuration

  Used to set up API keys, application keys, and other client settings.
• MonitorsApi

  from datadog_api_client.v1.api.monitors_api import MonitorsApi

  Example of importing a specific API endpoint client from 'v1'. Note: Many 'v1' endpoints are deprecated.
• MetricsApi

  from datadog_api_client.v2.api.metrics_api import MetricsApi

  Example of importing a specific API endpoint client from 'v2'. The 'v2' endpoints are generally preferred.
• Monitor

  from datadog_api_client.v1.model.monitor import Monitor

  Example of importing a model schema for API request bodies. Specific models reside within versioned 'model' subpackages.
• datadog
  This imports the *older* Datadog Python library, which is a separate package (pypi: `datadog`) and not `datadog-api-client`. Using this will result in different API methods and authentication.

Quickstart

This quickstart demonstrates how to authenticate with Datadog using API and Application keys (preferably from environment variables) and then create a new monitor using the `MonitorsApi` client. It also includes a comment for configuring regional endpoints.

import os
from datadog_api_client import ApiClient, Configuration
from datadog_api_client.v1.api.monitors_api import MonitorsApi
from datadog_api_client.v1.model.monitor import Monitor
from datadog_api_client.v1.model.monitor_type import MonitorType

# Configure API keys, preferably via environment variables
DD_API_KEY = os.environ.get('DD_API_KEY', '')
DD_APP_KEY = os.environ.get('DD_APP_KEY', '')

configuration = Configuration()
configuration.api_key['apiKeyAuth'] = DD_API_KEY
configuration.api_key['appKeyAuth'] = DD_APP_KEY

# For non-US regions, set the site explicitly:
# configuration.server_variables["site"] = "datadoghq.eu" # Example for EU site

try:
    with ApiClient(configuration) as api_client:
        api_instance = MonitorsApi(api_client)

        # Create a basic monitor example
        body = Monitor(
            name="Example Monitor - Python Client",
            type=MonitorType("metric alert"),
            query="avg(system.cpu.user{host:"test-host"}) by {host} > 80",
            message="CPU usage is high! @pagerduty",
            tags=["env:dev", "team:backend"],
            priority=3,
        )

        response = api_instance.create_monitor(body=body)
        print(f"Monitor created successfully: {response.name} (ID: {response.id})")

except Exception as e:
    print(f"Error creating monitor: {e}")