PagerDuty API

The common use is paging on your own rules: an agent raises a PagerDuty incident when a ticket meets the criteria in its instructions, keyed to the ticket so the ticket has at most one open incident, and keeps the incident in step with the ticket.

Automatically enabled when you configure PagerDuty permissions in your agent workflow, or on a dashboard.

What It Does

Raise an incident on a service, with the ticket’s title, details, urgency, priority and an incident key that ties the incident to the ticket
Add notes, acknowledge, reassign, escalate, snooze, merge or resolve incidents, and add responders
Read an incident’s log: who was paged, who acknowledged, when it escalated and resolved
Read who is on call now and on a date: on-calls, schedules, overrides and escalation policies; add an override
Read and change services, maintenance windows, event orchestrations, users and teams, Automation Actions, incident workflows, webhooks and status pages
Read incident and responder analytics and the audit trail

Permission Groups

Group	Covers
Incidents, Alerts & Notes	Incidents and their alerts, notes, log entries, responder requests, status updates, custom field values, reviews and related change events; priorities and notifications
On-Call, Schedules & Escalation	On-calls, schedules, their overrides, rotations and custom shifts, and escalation policies
Services, Event Routing & Incident Setup	Services and their integrations, event rules and custom fields, business services and dependencies, maintenance windows, event orchestrations, rulesets, alert grouping, enrichment, extensions, add-ons, standards, and incident types and custom fields
Users, Teams & Tags	Users and their contact methods and notification rules, teams and their members, and tags
Automation, Workflows & Webhooks	Automation Actions, their runners and invocations, incident workflows and their triggers, workflow integrations, webhook subscriptions and SRE Agent memories
Status Pages & Updates	Status pages and their posts, updates, postmortems and subscriptions, status dashboards and status update templates
Analytics, Audit & Account Security	Incident, responder and user analytics, the audit trail, licences and abilities, IP allow lists, session settings, OAuth delegations and user sessions

Access Profiles

Profile	What runs on its own	What asks a technician
Read Only	Every read	No write is allowed
Helpdesk	Every read	Raising and working incidents; no other write is allowed
IT Admin	Every read, and incident and on-call changes outside Safety Controls	Changes to services and event routing, users and teams, automation, status pages and account security, and the changes in Safety Controls
Full Automation	Every read and write outside Safety Controls	The changes in Safety Controls

Safety Controls

Control	Behavior
Always asks	Deleting a service, a user, a team, an event orchestration or one of its integrations; creating or changing a user or a user’s contact method; setting a team member’s role; signing people out and changing session settings; any IP allow list change; regenerating a user’s calendar feed key; every write that sets where PagerDuty sends data or what it shows from outside (a webhook subscription, an extension, a webhook OAuth client, a workflow integration connection, an Automation Action runner, an incident workflow, a status page subscription, an add-on, and an orchestration’s global, unrouted or service rules); and a write that sends a password, secret, token, routing key or credential header always ask a technician, whatever the profile
Incidents named by id	Neo changes several incidents or alerts at once only by their ids
One open incident per ticket	Each incident carries the ticket in its incident key, and Neo looks for an open one before it raises another; after it is resolved, a new one can be raised
Credentials in answers	Neo hides Events API routing keys, webhook secrets and credential headers, client secrets, passwords and tokens, and URLs that carry a credential, and cuts every URL outside pagerduty.com (webhook, extension, add-on, runner and workflow connection addresses) to its host, before the agent reads an answer. When the agent updates a record that holds a hidden value, such as an event orchestration rule with a webhook header, Neo puts the saved value back before the update reaches PagerDuty, and refuses the update if the agent changed that rule’s address
Author of each change	Every change names the PagerDuty user whose email you saved on the PagerDuty card

Getting started

Core

Triggered & Scheduled Agents

Chat Agents

Integrations

Product

Workflows

Customizing Neo

What It Does

Permission Groups

Access Profiles

Safety Controls

​What It Does

​Permission Groups

​Access Profiles

​Safety Controls

What It Does

Permission Groups

Access Profiles

Safety Controls