Claude, Datadog API. — YouTube metadata
Claude does not automatically know an outside API such as Datadog's. This video shows how a skill file carries the account-specific details, and why it works as a map of traps rather than knowledge, helping only where the map is explicit.
Does Claude already know how an outside system like Datadog's API works, or does something have to tell it? The video's answer is that it needs to be told. Claude reads a skill, which is a file, before acting, and that file carries the account-specific detail training alone would not reliably supply.
Which version covers which resource
The Datadog API splits into v1 and v2 according to what you are asking for, not according to which version is newer. V1 covers metrics, monitors, dashboards, and service levels. V2 covers logs, traces, incidents, and session data. A skill that records this split saves Claude from reaching for the wrong one.
Two headers and one regional trap
Every request Claude sends carries two headers. One identifies the account, and the other identifies who is calling and what they are allowed to touch.
The sharpest trap is regional. Datadog runs several separate regional addresses, and calling the wrong one returns a flat permission error even when the keys are valid. The skill's fix has two parts: set the region first, then make one throwaway call to the validate endpoint to confirm it before doing anything real.
Three ways results are paged
Long results arrive a page at a time, and the scheme depends on the endpoint:
- Logs, events, and traces hand back a cursor that is passed forward until it is empty.
- Monitors use a page number.
- Incidents and users use a page size and an offset.
Quirks that survive even with the file
The video highlights two real JSON:API quirks. One endpoint wraps its results one layer deeper than the others, so the same shape of request needs extra nesting, and the error returned does not say which field was wrong. The second is that updating a dashboard replaces the whole document, so a widget left out of the update is removed rather than skipped.
Documented plainly versus easy to miss
Having the file does not mean Claude never trips. Where the file states something plainly, such as the region check or the exact error text a missing flag produces, Claude follows it and avoids the mistake. Where a point is buried in a single line or never flagged as a trap, Claude can still get it wrong, much as a person skimming the same page could. The carry-out is that a skill does not make Claude know an API. It gives Claude a map of where the traps are, and Claude only avoids the ones the map marks.
Key takeaways
- Claude does not automatically know an outside API; a skill file supplies the specifics.
- Datadog splits v1 and v2 by resource, not by age.
- Two headers are needed on every request.
- Wrong regional addresses give a permission error even with valid keys.
- Set the region, then confirm with the validate endpoint.
- Pagination uses cursors, page numbers, or size with offset depending on the endpoint.
- One endpoint nests results deeper, and its errors do not name the faulty field.
- Dashboard updates replace the whole document.
Try it yourself
Choose an API you have not used with Claude before, even a small public one. Before it writes any code, ask Claude to list the three things it would need confirmed: how requests are authenticated, how paginated results come back, and any regional or versioning quirk. Then have it write the first real call and check whether it used that list. The Datadog skill is in the humanitarians-youtube repository.
Chapters
Full transcript(auto-generated, with timestamps)
Cold open — does Claude already know the Datadog API?
[0:00]Someone assumed Claude already knows how to work with an outside system like DataDog's API. Not quite. It gets shown in a file it reads before acting. Here's what that file actually has to spell out. The DataDog API splits in two by
Anatomy — v1/v2 resource split + setup requirements
[0:13]What you're asking for, not by which version is newer. V1 covers metrics, monitors, dashboards, and service levels. V2 covers logs, traces, incidents, and session data. Two headers ride on every request Claude sends. One says which account you're in, one says who you are and what you're allowed to touch. The sharpest trap is regional. DataDog runs several separate regional addresses. And calling the wrong one returns a flat permission error even with valid keys. The skills fix, set the region first, then make one throwaway call, the validate endpoint, just to confirm it before doing anything real.
Design — three pagination schemes + JSON:API traps
[0:46]Long results come back a page at a time, and DataDog uses three different schemes for that, depending which endpoint you're calling. Logs, events, and traces hand back a cursor, pass it forward, and stop once it's empty. Monitors use a page number instead. Incidents and users use a page size and offset. Two more things Claude has to track. One endpoint wraps its results one layer deeper than the rest. So, the exact same shape of request needs extra nesting most other endpoints skip, miss it, and the error that comes back doesn't say which field was wrong. And updating a dashboard replaces the whole document. Leave a widget out of the update and it's gone, not skipped. So, does having this file
Both directions — documented plainly vs. easy to miss
[1:22]Mean Claude never trips? Not exactly. Where the file spells something out plainly, the region check, the exact error text a missing flag produces, Claude follows it and skips the mistake entirely. Where it's buried in one line or never flagged as a trap at all, Claude can still get it wrong the same way a person skimming the same page would. A skill doesn't make Claude know
Carry-out
[1:42]An API. It gives Claude a map of where the traps are, and Claude only avoids the ones the map actually marks. Your
Your turn
[1:49]Turn. Here's the prompt. Read it with me. Pick an API you've never used with Claude before, even a small public one. Before you let it write any code, ask it to list the three things it would need confirmed first. How requests are authenticated, how paginated results come back, and any known regional or versioning quirk. Then have it write the first real call and check whether it actually used what it just told you it needed. Claude DataDog API Lay them in
Outro
[2:12]For bear.
