You need an API key and an application key before you can make a single call. That's two keys, two permissions scopes, and a paid account.
Datadog's API is well-documented. The endpoints are clean, the response shapes are consistent, and the SDKs cover every major language.
The problem is testing.
Two keys before you start
To call any Datadog endpoint, you need:
- A
DD-API-KEY— tied to your organization - A
DD-APPLICATION-KEY— tied to a specific user with specific permissions
You can't get either without a Datadog account. Free trials exist, but they require a credit card and install an agent on your infrastructure.
If you're building an integration — say, a dashboard that pulls monitors and incidents, or a CI pipeline that posts deployment events — you have to set all of that up before you can test whether your code handles the response correctly.
The shape matters more than the data
Most of the time, what you actually need to validate isn't "does Datadog return my real monitors." It's:
- Does my code handle the pagination format?
- What does the response look like when a monitor has no tags?
- What happens when I create an incident and immediately query it — does the state transition work?
These are integration logic questions, not data questions. You don't need your production monitors to answer them.
Testing the flow without an account
FetchSandbox has a Datadog v2 sandbox with every endpoint callable immediately. No keys, no agent install, no account.
The sandbox is stateful — create a monitor, then list monitors, and the one you just created shows up. Create an incident, transition it to resolved, and the state change persists.
A workflow that tests the incident lifecycle:
-
POST /api/v2/incidents— create an incident -
GET /api/v2/incidents/{id}— verify it exists with statusactive -
PATCH /api/v2/incidents/{id}— transition toresolved -
GET /api/v2/incidents/{id}— confirm the state changed
Each step chains IDs from the previous one. The sandbox handles this automatically.
Where this matters
If you're building Datadog integrations and your test suite currently requires a live Datadog org, every test run is a network call to production. When Datadog has an outage or rate-limits your key, your CI breaks for reasons that have nothing to do with your code.
Running the same tests against a sandbox that behaves like the real API — but doesn't require auth or network — isolates the thing you're actually testing: your integration logic.
Try the Datadog sandbox — no signup, runs in your browser.
