Datadog package v1.0.0

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 establishes that disabling a user account revokes every application key that user created (API keys created by the disabled account are not deleted and remain valid), so owning the application keys with a dedicated service account keeps user offboarding from silently breaking the pack.

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.

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.

Approval classification: the downtime capability is registered as create and send at the minimum R3 tier — 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 designated actions requiring human approval.

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).

Excluded operations: 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.