datadog v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-datadog-api-key

Custody

customer_vault

Injection

header (DD-API-KEY)

A Datadog org API key plus a scoped application key for the customer's own org, held in the client's own secret manager. Datadog requires two headers on each of the registered operations: DD-API-KEY and DD-APPLICATION-KEY. The pack format models one injection point per credential, so this pack declares the DD-API-KEY header and the stored material under the reference is the complete header value for it — the API key itself, with no scheme prefix. The second header is wiring the deployment must complete honestly: store the application key under its own reference and configure the HTTP connector to emit DD-APPLICATION-KEY alongside DD-API-KEY on every call; a deployment that can inject only one header fails closed (Datadog answers 403), and it must not work around the gap by embedding the application key in code or config outside custody. Application keys are scoped and are associated with the user or service account that created them, by default carrying that account's permissions: create both keys under a dedicated least-privilege service account and grant exactly the application-key authorization scopes the cited API reference pages list for these five operations — the documented read scopes for the four reads, and the documented downtime write scope only where the downtime capability is enabled — noting that scopes set on the key persist even if the owning account's role later changes. Neither key expires on its own, and the two key types have different lifecycles: an API key is an org-level value revoked by deleting it in Datadog organization settings, while an application key is owned by the user or service account that created it and is revoked by deleting that key; the cited documentation does not establish the effect of disabling or deleting the owning account on that account's application keys, so the deployment must verify that behavior for its org rather than assume the keys survive account disablement — owning the application keys with a dedicated service account keeps that question off the user-offboarding path. Restricting new key issuance does not invalidate keys already issued of either type. Renewal and rotation therefore sit with an external deployment process: the executor injects the stored values verbatim and performs no key lifecycle of its own. On newer orgs application key secrets are shown once at creation (One-Time Read mode), so capture the value into the vault at creation time. Executor hygiene: the values must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

• datadog-monitors (api, internal): https://api.datadoghq.com/api/v1/monitor
• datadog-hosts (api, internal): https://api.datadoghq.com/api/v1/hosts
• datadog-events (api, internal): https://api.datadoghq.com/api/v2/events
• datadog-incidents (api, pii): https://api.datadoghq.com/api/v2/incidents

The registered host 'api.datadoghq.com' is Datadog's real US1 API host — a shared SaaS authority, not a placeholder. Datadog is per-site: if the customer's org is not on US1, substitute the site API host (api.us3.datadoghq.com, api.us5.datadoghq.com, api.ap1.datadoghq.com, api.ap2.datadoghq.com, api.uk1.datadoghq.com, api.datadoghq.eu, api.ddog-gov.com or api.us2.ddog-gov.com per the Datadog sites documentation) in the endpoints, the resource locators and the egress allowlist — the allowlist matches exactly, so all three must be substituted together before enabling. Every read endpoint here is a COLLECTION read only: single-record reads (GET /api/v1/monitor/{monitor_id}, GET /api/v2/events/{event_id}, GET /api/v2/incidents/{incident_id}) are not registered. Effect-level tiering: the downtime capability is registered as create and send at the R3 floor — a downtime globally suppresses monitor notifications for its scope (suppressing alerts can hide incidents from the people who would have been paged), and the downtime object's documented message and end-notification settings can themselves notify recipients, an unrestricted notification-capable effect that cannot be un-delivered; send is one of the IRREVERSIBLE ACTIONS. Not every downtime has a finite end — the documented schedules include no-end and recurring forms — so self-expiry cannot justify a lower tier even though a scheduled downtime can be cancelled (DELETE /api/v2/downtime/{downtime_id}, not registered). Documented exclusions — this pack does not register: monitor creation, edit, deletion, validation or mute/unmute (including the deprecated mute_all), host mute/unmute, downtime update or cancel, incident creation, update, deletion, impacts, todos, attachments, notification rules or settings, event posting — the v2 Event Management intake (POST /api/v2/events) is served from a separate event-management-intake.<site> host that no capability here may reach, while the deprecated v1 event intake (POST /api/v1/events) is served from the registered API host and is equally not registered by this pack, monitor notification rules, configuration policies, the logs/events search APIs with caller-controlled query text (POST /api/v2/events/search), usage metering, key management, and every other Datadog API — a documented exclusion, not an approximated capability.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://docs.datadoghq.com/api/latest/monitors/ (retrieved 2026-09-21)
• https://docs.datadoghq.com/api/latest/hosts/ (retrieved 2026-09-21)
• https://docs.datadoghq.com/api/latest/events/ (retrieved 2026-09-21)
• https://docs.datadoghq.com/api/latest/incidents/ (retrieved 2026-09-21)
• https://docs.datadoghq.com/api/latest/downtimes/ (retrieved 2026-09-21)
• https://docs.datadoghq.com/getting_started/site/ (retrieved 2026-09-21)
• https://docs.datadoghq.com/account_management/api-app-keys/ (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.