Authentication overview

The Datadog API employs a credential-based authentication model designed to secure programmatic access to its platform. This model primarily uses two distinct types of keys: the API Key and the Application Key. The API Key serves to identify your organization within the Datadog ecosystem, granting access to your account's data and resources. It is considered a global identifier for your Datadog account. In contrast, the Application Key is associated with a specific user or application within your organization and is used to authorize individual requests. This dual-key structure enables granular control and auditing of API interactions, distinguishing between organizational identity and individual client identity. All requests to the Datadog API are required to include both keys for successful authentication and authorization, ensuring that both the originating organization and the specific client are verified before processing the request. This approach is consistent across various API endpoints, whether you are submitting metrics, managing monitors, or querying historical data, as detailed in the Datadog API authentication documentation. Users developing with Datadog's client libraries in languages such as Python, Go, or Java will integrate these keys into their client configurations.

Supported authentication methods

Datadog API primarily relies on a signature-based authentication mechanism where requests are authenticated through the provision of an API Key and an Application Key. These keys are passed as HTTP headers or query parameters with each API request. This method is a common approach for securing access to RESTful APIs, providing a straightforward mechanism for clients to prove their identity and authorization. The system does not currently support more complex token-based authentication flows such as OAuth 2.0 directly for API key management, though OAuth 2.0 is a prevalent standard for delegated authorization in many other API contexts, as described by the OAuth 2.0 RFC 6749 specification. For Datadog, the combination of API and Application Keys effectively manages access control for its specific use cases.

The following table summarizes the primary authentication method:

Method When to Use Security Level
API Key + Application Key All programmatic interactions with the Datadog API for account-level and user-specific access. High (when keys are managed securely and rotated regularly).

For server-side applications and integrations, these keys are typically stored as environment variables or within secure configuration management systems. Client-side applications, such as browser-based UIs, should avoid direct exposure of these keys and instead route API requests through a secure backend proxy to protect credentials from client-side inspection. The Datadog API reference provides specific examples for integrating these keys into various HTTP clients and SDKs.

Getting your credentials

To obtain the necessary API and Application Keys for authenticating with the Datadog API, you must generate them through the Datadog web interface. Both types of keys are managed under the 'Organization Settings' section.

API Key Generation

  1. Log in to your Datadog account.
  2. Navigate to 'Organization Settings' > 'API Keys'.
  3. Click the 'New API Key' button.
  4. Provide a descriptive name for your API Key. This name helps in identifying the key's purpose and managing its lifecycle.
  5. The new API Key will be generated and displayed. It is crucial to copy this key immediately, as it will not be displayed again for security reasons. Treat your API Key as a sensitive secret.

Application Key Generation

  1. Log in to your Datadog account.
  2. Navigate to 'Organization Settings' > 'Application Keys'.
  3. Click the 'New Application Key' button.
  4. Enter a meaningful name for the Application Key, indicating the specific application or service that will use it.
  5. The new Application Key will be generated and displayed. Similar to API Keys, copy this key as it will only be shown once.

It is recommended to generate separate Application Keys for each distinct application or service that interacts with the Datadog API. This practice enhances security by allowing you to revoke access for a specific application without affecting others, and it improves auditability by providing clear visibility into which application is making requests. The Datadog API and Application Keys documentation offers further guidance on key management.

Authenticated request example

When making authenticated requests to the Datadog API, both the API Key and Application Key are typically included as HTTP headers. The specific header names are DD-API-KEY for your API Key and DD-APPLICATION-KEY for your Application Key.

Here's an example using curl to fetch a list of all active monitors:

curl -X GET "https://api.datadoghq.com/api/v1/monitor" \
     -H "Accept: application/json" \
     -H "DD-API-KEY: <YOUR_DATADOG_API_KEY>" \
     -H "DD-APPLICATION-KEY: <YOUR_DATADOG_APPLICATION_KEY>"

In this example:

  • -X GET specifies the HTTP method.
  • "https://api.datadoghq.com/api/v1/monitor" is the endpoint for retrieving monitors.
  • -H "Accept: application/json" indicates that the client expects a JSON response.
  • -H "DD-API-KEY: <YOUR_DATADOG_API_KEY>" includes your organization's API Key.
  • -H "DD-APPLICATION-KEY: <YOUR_DATADOG_APPLICATION_KEY>" includes the Application Key for the specific client.

When using an official Datadog SDK, the keys are typically configured when initializing the client. For instance, in Python:

from datadog_api_client import ApiClient, Configuration
from datadog_api_client.v1.api.monitors_api import MonitorsApi

configuration = Configuration(
    api_key={
        "apiKeyAuth": "<YOUR_DATADOG_API_KEY>",
        "appKeyAuth": "<YOUR_DATADOG_APPLICATION_KEY>",
    }
)

with ApiClient(configuration) as api_client:
    api_instance = MonitorsApi(api_client)
    response = api_instance.list_monitors()
    print(response)

This Python example demonstrates how the Configuration object in the Datadog API client is initialized with both the API Key and Application Key. Subsequent calls using api_instance will automatically include these credentials in the request headers. Developers can find more detailed examples and SDK-specific instructions in the Datadog Monitors API documentation.

Security best practices

Securing your Datadog API and Application Keys is critical to maintaining the integrity and confidentiality of your monitoring data and infrastructure. Adhering to established security practices can mitigate risks associated with credential compromise.

1. Principle of Least Privilege

Generate separate Application Keys for each distinct application, service, or team that interacts with the Datadog API. This allows you to grant only the necessary permissions for each key, limiting the potential impact if a key is compromised. Avoid using a single key across multiple services. For example, a service that only needs to submit metrics should not have an Application Key with permissions to manage monitors.

2. Secure Storage of Credentials

Never hardcode API or Application Keys directly into your application's source code. Instead, store them in secure environments:

  • Environment Variables: For server-side applications, use environment variables. This keeps keys out of version control and easily configurable.
  • Secret Management Services: Utilize dedicated secret management solutions such as AWS Secrets Manager, Google Secret Manager, or HashiCorp Vault. These services provide secure storage, access control, and auditing capabilities for secrets.
  • Configuration Files (Encrypted): If storing in configuration files, ensure they are encrypted and access is restricted.

3. Key Rotation

Regularly rotate your API and Application Keys. This practice reduces the window of opportunity for a compromised key to be exploited. While there isn't a universally mandated rotation frequency, a quarterly or bi-annual rotation is a common recommendation for many API security guidelines. When rotating, generate a new key, update your applications to use the new key, and then revoke the old key. The Datadog documentation on revoking API keys provides instructions for this process.

4. Restrict Access to Key Management

Limit the number of users within your organization who have permissions to generate, view, or revoke API and Application Keys. Implement strong access controls and multi-factor authentication for Datadog accounts with key management privileges.

5. Monitor API Key Usage

Regularly review audit logs and API usage metrics within Datadog to identify any unusual activity associated with your keys. Sudden spikes in requests, requests from unexpected geographical locations, or attempts to access unauthorized endpoints could indicate a compromised key. Datadog provides Audit Trail features which can assist in monitoring key usage.

6. Revoke Compromised or Unused Keys

Immediately revoke any API or Application Key that is suspected of being compromised or is no longer in use. Unused keys pose an unnecessary security risk. Regularly audit your keys and remove those that are no longer required.

7. Secure Communication

Always ensure that all communication with the Datadog API occurs over HTTPS to encrypt data in transit and prevent eavesdropping or tampering. Datadog API endpoints enforce HTTPS by default, aligning with web security standards like those outlined by the W3C's Content Security Policy recommendations for secure transport.

By implementing these best practices, developers and organizations can significantly enhance the security posture of their Datadog API integrations.