Integrations and Developer Platform
This domain tests how external systems connect to PagerDuty and how developers extend it. It covers inbound and outbound integrations, Events API v2, REST API, webhooks, authentication, and the developer platform (apps, actions, OAuth).
Core rules
- Inbound integrations create incidents from monitoring and alerting tools. The Events API v2 uses a routing_key (integration key), event_action (trigger, acknowledge, resolve), dedup_key, and payload; it is designed for high-volume alert traffic.
- Outbound integrations send PagerDuty activity to other tools: webhooks, Slack, Microsoft Teams, ServiceNow, and Jira. Webhooks v3 include signatures for verification and may retry, so consumers must handle duplicates idempotently.
- REST API is for managing configuration and reading or writing resources such as services, users, schedules, and incidents. API keys and OAuth scopes control access. Do not use REST API for high-volume event ingestion when Events API fits.
- Developer Platform: PagerDuty Apps run in the UI with scoped OAuth; App Actions let responders invoke actions; custom event transformers and orchestration can normalize payloads.
- Change Events API records deployments and configuration changes for correlation; it is separate from incident events.
Worked example
A monitoring tool sends a trigger event to Events API v2 with routing_key "abc123", dedup_key "host-42-disk", and severity critical. PagerDuty opens an incident. When disk usage clears, the tool sends event_action resolve with the same routing_key and dedup_key; PagerDuty resolves the same incident. A webhook subscription sends the incident event to an internal audit service; the service verifies the signature and deduplicates by webhook event ID. Reasoning: the same dedup_key ties trigger and resolve; webhook idempotency prevents duplicate audit records.
Traps
- Sending a new dedup_key on resolve; the original incident stays open.
- Using REST API for every alert; rate limits and latency make Events API the right path.
- Ignoring webhook signature verification and retry duplicates.
- Requesting broad OAuth scopes for an app; least privilege is expected.