ExamFinch.com My Study

Study guide

API Endpoints for Data

Practice this exam

Datadog Fundamentals Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Computer Fundamentals

Datadog Cert Format and Study Map Shell, OS, and Processes Networking Basics for Observability Hardware, Metadata, and Config Files Linux/Windows Troubleshooting Basics

2 Infrastructure Development

2.1 Agent Install and Architecture 2.2 API Keys and Application Keys 2.3 Running the Agent and Status 2.4 Hostnames and Environments

3 Networking and Agent Configuration

Datadog Ports and Endpoints Datadog IPs and Connectivity Autodiscovery Patterns

4 Data Collection

DogStatsD and Custom Metrics Integrations and Crawlers API Endpoints for Data Tagging Best Practices Metrics, Timeseries, and Types

5 Troubleshooting Datadog

Agent Commands and Flare Agent Logs and Debug Config File Troubleshooting

6 Data Visualization and Utilization

6.1 Host Map and Infrastructure List 6.2 Dashboards and Widgets 6.3 Monitors, Alerts, and Notifications 6.4 Investigation Workflows and Exam Tips

API Endpoints for Data

Key Takeaways Explain This Topic AI

Datadog's HTTP API accepts metrics, logs, events, and traces when Agent-based collection is not practical.

The metrics submission endpoint (POST /api/v1/series) sends custom timeseries data directly to Datadog intake.

API keys authenticate the organization; application keys authorize the calling user for most read and many write API operations.

The site parameter (datadoghq.com, datadoghq.eu, us3.datadoghq.com, etc.) must match your organization's Datadog region.

Official API clients default to the US site — EU and other regions require explicit host or site configuration.

Last updated: July 2026

Quick Answer: Datadog exposes an HTTP REST API for submitting and managing telemetry. For custom metrics without an Agent, use the metrics submission API ( POST /api/v1/series ). Writes require an API key ; most reads and many management calls also need an application key . Point clients at the correct site ( datadoghq.com , datadoghq.eu , etc.).

While DogStatsD and Agent integrations cover most production paths, the Fundamentals exam also tests direct API submission — serverless functions, CI pipelines, external cron jobs, and third-party systems that cannot run an Agent. Understanding intake endpoints, authentication, and regional sites prevents the classic "API returns 200 but data never appears" failure mode.

Intake Endpoints by Signal Type

Datadog organizes public intake around signal families:

  • Signal Typical Use Case API Family
  • Metrics Business KPIs from serverless, batch jobs Metrics API — /api/v1/series
  • Logs Centralized log forwarding without Agent tailing Logs API — HTTP log intake
  • Events Deployment markers, incident annotations Events API — /api/v1/events
  • Traces APM from instrumented services Trace intake API

On the Exam: Match the signal to the endpoint family. "Submit custom metric from Lambda" → metrics API . "Post deployment notification" → events API . Distractors often cite Monitors Search or Host Map APIs, which query existing data rather than ingest new telemetry.

  • Metrics API: Direct Timeseries Submission
  • When no Agent is available, POST JSON to the series endpoint: POST https://api.<SITE>/api/v1/series

Payload structure (simplified):

  • Field Purpose
  • series[].metric Metric name (e.g., batch.records.processed )
  • series[].points Array of [timestamp, value] pairs
  • series[].type Metric type: gauge, count, rate
  • series[].tags Optional tag array ( env:prod , job:nightly )

Authentication headers include DD-API-KEY . High-volume production workloads still prefer DogStatsD when an Agent is nearby because HTTP per-point costs more overhead.

When to Choose API vs DogStatsD

  • Situation Recommended Path
  • Long-running app on host with Agent DogStatsD
  • AWS Lambda function Metrics API (or Lambda extension forwarding to Agent)
  • External partner sending occasional KPIs Metrics API
  • High-frequency app metrics on Kubernetes node with Agent DogStatsD
  • Authentication: API Keys and Application Keys
  • Key Type Identifies Required For
  • API key Your Datadog organization Virtually all API writes; Agent forwarding
  • Application key A specific user or service account Most read APIs; many management operations

The Agent needs only an API key to forward host data. Scripts that search monitors , create dashboards , or read events via API typically need both keys. Exam stems about "programmatically manage Datadog resources" usually imply the key pair, not API key alone.

Common Trap: Application keys are not required for DogStatsD traffic or basic Agent metric forwarding. Requiring an app key for every Agent install is a distractor.

Regional Sites and API Hostnames

Datadog accounts are tied to a site (region). Data sent to the wrong site does not appear in your organization's UI.

  • Site Parameter API Host (example)
  • datadoghq.com (US1, default) api.datadoghq.com
  • datadoghq.eu (EU1) api.datadoghq.eu
  • us3.datadoghq.com api.us3.datadoghq.com
  • us5.datadoghq.com api.us5.datadoghq.com
  • ap1.datadoghq.com api.ap1.datadoghq.com

Configure site in:

  • Agent: site: in datadog.yaml or DD_SITE environment variable
  • API clients: api_host / server_variables["site"] depending on library
  • curl: correct hostname in the URL

Official Python, Go, and Java clients default to the US site . An EU organization that forgets to set site will authenticate successfully against the wrong region or see empty query results.

Logs and Events API Overview

Logs API intake suits centralized forwarders, serverless log shipping, or custom appenders. Payloads include message body, timestamp, ddsource , service , hostname , and tags — mirroring Agent log pipeline metadata.

Events API posts structured occurrences visible in the Event Stream and correlatable with metrics. Common uses: deployment markers ( title , text , tags , alert_type ), autoscaling notifications, or change-management audit trails.

Neither replaces Agent log tailing on a host — that still requires Agent configuration for file paths — but both are valid when the Agent is not in the path.

Worked Scenario: Nightly ETL Batch Metric

A data team runs a nightly ETL job on a serverless runner with no Agent. They need etl.rows.loaded with tags env:prod and pipeline:orders .

Store the API key in the runner's secret manager.

At job completion, POST to https://api.datadoghq.com/api/v1/series (or EU equivalent).

Include gauge points with Unix epoch timestamps and tags.

Confirm in Metrics Explorer within minutes.

If the metric never appears but curl returns success, check site , API key organization , and metric name typos before opening a support ticket.

API Clients and Automation

Datadog publishes official client libraries (Python datadog-api-client , Go, Java, Ruby, etc.) wrapping authentication, pagination, and retries. Infrastructure-as-code tools like the Terraform Datadog provider also call the same API surface with API + application keys.

For Fundamentals, you do not need endpoint URL memorization beyond knowing metrics → series endpoint , keys → API + app for management , and site → must match org region . Scenario reasoning beats rote URL recall.

Rate Limits and Payload Size

High-volume API submissions should batch multiple points per request and respect documented rate limits. For burst traffic without an Agent, consider a small forwarder service that buffers and retries rather than embedding raw HTTP calls in every code path — the exam focuses on which endpoint to use, not enterprise throughput tuning.