> ## Documentation Index > Fetch the complete documentation index at: https://docs.atako.ai/llms.txt > Use this file to discover all available pages before exploring further. # PagerDuty > Connect PagerDuty to your Atako agents — 11 read and 4 write actions. Let your agents read services, on-call schedules and incidents, and create, acknowledge, resolve and annotate incidents via the PagerDuty REST API. ## Connection * **Authentication**: API key (REST API key). * **Required settings**: * **Region** — Use "api" for a US account (api.pagerduty.com) or "api.eu" for an EU account (api.eu.pagerduty.com). Sign in to PagerDuty as an Admin or Account Owner → Integrations → Developer Tools → API Access Keys → Create New API Key. Enter a Description, tick "Read-only API Key" only if your agents should never change incidents, click Create Key and copy the key (it is shown only once). For an EU account, choose the "api.eu" region. See [PagerDuty's documentation](https://support.pagerduty.com/main/docs/api-access-keys). ## Read actions (11) | Action | Description | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `get_incident` | Get a single incident by its ID (e.g. "PT4KHLK") — the id field, not the incident number. | | `get_service` | Get a single service by its ID (e.g. "PWIXJZS"). | | `list_escalation_policies` | List escalation policies. Optional: query (filter on name), sort\_by ("name", "name:asc" or "name:desc"), limit (1-100), offset. | | `list_incident_log_entries` | List the log entries (timeline: triggers, notifications, acknowledgements, escalations) of an incident. Optional: since/until (ISO 8601), is\_overview (boolean, only the most important changes), limit (1-100), offset. | | `list_incident_notes` | List the notes added to an incident. | | `list_incidents` | List incidents. since/until (ISO 8601) default to the last month, maximum range 6 months; date\_range "all" ignores them. Filters take ONE value each: status ("triggered", "acknowledged" or "resolved"), urgency ("high" or "low"), service\_id. Optional: incident\_key, sort\_by (e.g. "created\_at:desc"; fields incident\_number, created\_at, resolved\_at, urgency; up to two, comma-separated), limit (1-100), offset. | | `list_oncalls` | List who is on call. Filters take ONE value each: schedule\_id, escalation\_policy\_id, user\_id. Optional: since/until (ISO 8601), earliest (boolean, only the earliest on-call per policy/level/user), limit (1-100), offset. | | `list_priorities` | List the incident priorities of the account (e.g. P1…P5). Empty when priorities are disabled. Use it to find the priority\_id accepted by create\_incident. | | `list_schedules` | List on-call schedules. Optional: query (filter on name), limit (1-100), offset. | | `list_services` | List services (id, name, status, escalation policy). Optional: query (filter on name), sort\_by ("name", "name:asc" or "name:desc"), limit (1-100), offset. Use it to find the service\_id required by create\_incident. | | `list_users` | List users of the account (id, name, email, role). Optional: query (filter on name or email), limit (1-100), offset. Use it to find a valid from\_email for the write actions. | ## Write actions (4) | Action | Description | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `acknowledge_incident` | Acknowledge an incident (stops its escalation). Sends \{ incident: \{ type: "incident\_reference", status: "acknowledged" } }. Arguments: incident\_id: string (incident ID, e.g. "PT4KHLK"); from\_email: string (e-mail of a PagerDuty user of the account, sent as the From header). | | `add_incident_note` | Add a note to an incident. Sends \{ note: \{ content } }. Arguments: incident\_id: string (incident ID); from\_email: string (e-mail of a PagerDuty user of the account, sent as the From header and shown as the note author); content: string (plain text of the note). | | `create_incident` | Create (trigger) an incident. Flat arguments, wrapped for you into \{ incident: \{ type: "incident", … } }: from\_email: string (e-mail of a PagerDuty user of the account, sent as the From header — see list\_users); title: string; service\_id: string (see list\_services); urgency: optional string "high" or "low"; details: optional string (incident body text) or JSON object; escalation\_policy\_id: optional string (see list\_escalation\_policies); priority\_id: optional string (see list\_priorities); incident\_key: optional string (deduplication key — an open incident with the same key is rejected). | | `resolve_incident` | Resolve an incident. Sends \{ incident: \{ type: "incident\_reference", status: "resolved", resolution? } }. Arguments: incident\_id: string (incident ID); from\_email: string (e-mail of a PagerDuty user of the account, sent as the From header); resolution: optional string (resolution note, added to the incident log). | ## Permissions Every action above must be explicitly granted to an agent before it can be used. See [Permissions](/integrations/permissions) for the grant model and [Security](/integrations/security) for how credentials are protected.