pagerduty 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-pagerduty-api-token

Custody

customer_vault

Injection

header (Authorization)

A PagerDuty REST API access token for the customer's own account, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Token', the literal parameter name 'token=', then the key — 'Token token=<API_KEY>' — exactly as PagerDuty's published API schema defines the security scheme. A general access key inherits account-wide permissions and a user token key is restricted to the issuing user's own permissions, so issue the token at the least privilege that covers these reads and, where enabled, incident updates; a read-only general access key (a documented creation option that restricts the key to GET calls) covers the four reads only. PagerDuty documents that writes made with a general access REST API key require a From header carrying the login email of a PagerDuty user on the account — the acting user recorded for the change — while a user token key acts as its issuing user without one; the deployment wiring the incident update capability with a general access key must emit that From header alongside Authorization, and one that cannot must use a user token key or leave the write disabled. PagerDuty REST API keys do not expire on their own, and PagerDuty documents two distinct controls for general access keys: disabling a key stops it working with the REST API but can be reversed by re-enabling it, while deleting a key permanently removes it; user token keys are deleted by their owner or an admin. Restricting who can create keys does not invalidate keys already issued. Rotation therefore sits with an external deployment process: the executor injects the stored value verbatim and performs no token lifecycle of its own. Executor hygiene: the value 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.

• pagerduty-incidents (api, pii): https://api.pagerduty.com/incidents
• pagerduty-services (api, internal): https://api.pagerduty.com/services
• pagerduty-users (api, pii): https://api.pagerduty.com/users
• pagerduty-oncalls (api, pii): https://api.pagerduty.com/oncalls

The registered host 'api.pagerduty.com' is PagerDuty's real REST API host for the US service region — a shared SaaS authority, not a placeholder; accounts in the EU service region use the regional host api.eu.pagerduty.com, which the deployment substitutes into the endpoints, the resource locators and the egress allowlist together — the allowlist matches exactly, so all three must move as one. INCIDENT_ID in the incident-update path is a placeholder the deployment substitutes with a concrete incident id at registration time, before enabling. Every read endpoint here is a COLLECTION read only: single-record reads (GET /incidents/{id}, GET /services/{id}, GET /users/{id}) are not registered. Effect-level tiering: the incident update capability is registered as update and send at the R3 floor because the registered PUT performs every transition PagerDuty documents for it — acknowledge, resolve, escalate and reassign — and escalating or reassigning notifies or wakes another responder: send, one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer). The registration prices the effect the endpoint actually enables, not the subset an installer intends; the mass-manage variant PUT /incidents is not registered. Documented exclusions — this pack does not register: incident creation (POST /incidents — declaring an incident notifies responders, a send-class effect), incident notes, alerts, any service, user, escalation-policy, schedule or team write, response plays, and the Events API (a separate host, events.pagerduty.com, that no capability here may reach) — 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://raw.githubusercontent.com/PagerDuty/api-schema/main/reference/REST/openapiv3.json (retrieved 2026-09-21)
• https://support.pagerduty.com/main/docs/api-access-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.