# PagerDuty PagerDuty helps you proactively manage your digital operations by collecting data signals from anywhere, interpreting those signals using machine learning, automatically engaging the right people, and accelerating resolution and learning. - **Category:** server monitoring - **Auth:** OAUTH2, API_KEY - **Composio Managed App Available?** No - **Tools:** 368 - **Triggers:** 0 - **Slug:** `PAGERDUTY` - **Version:** 20260316_00 ## Tools ### Add service to incident workflow trigger **Slug:** `PAGERDUTY_ADD_SERVICE_TO_INCIDENT_WORKFLOW_TRIGGER` Adds a service to an existing incident workflow trigger in PagerDuty, enabling the trigger to fire for incidents on that service. Associates a specific service with an incident workflow trigger to automate incident management for that service. Prerequisites: - The incident workflow trigger must already exist (create with CREATE_A_TRIGGER) - The service must already exist in your account - The trigger must not be subscribed to all services Use when expanding automated workflows to additional services or incrementally rolling out workflows. This is an additive operation - use DELETE_INCIDENT_WORKFLOW_TRIGGER_SERVICE to remove services. Requires incident_workflows:write OAuth scope. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident workflow trigger to which the service will be added. | | `service__id` | string | Yes | The ID of the PagerDuty service to associate with this incident workflow trigger. The service must already exist in your account. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Aggregate escalation policy incident metrics **Slug:** `PAGERDUTY_AGGREGATE_ESCALATION_POLICY_INCIDENT_METRICS` This endpoint analyzes and aggregates incident metrics across all escalation policies in PagerDuty. It allows for detailed filtering and customization of the analysis, enabling users to gain insights into incident patterns, response times, and escalation effectiveness. The endpoint is particularly useful for operational reviews, performance analysis, and identifying areas for improvement in incident management processes. It provides flexibility in data selection through various filters and supports different time-based aggregations for comprehensive reporting. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `order` | string ("asc" | "desc") | No | The order in which the results were sorted; asc for ascending, desc for descending. | | `order_by` | string | No | The column that was used for ordering the results. | | `time_zone` | string | No | The time zone to use for the results and grouping. Must be in tzdata format. See list of accepted values [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). | | `aggregate_unit` | string ("day" | "week" | "month") | No | The time unit to aggregate metrics by. If no value is provided, the metrics will be aggregated for the entire period. | | `filters__major` | boolean | No | A boolean flag including whether results should contain *only* [major incidents](https://support.pagerduty.com/docs/operational-reviews#major-incidents), or exclude major incidents. If no value is provided all incidents will be included. | | `filters__urgency` | string ("high" | "low") | No | Any incidents whose urgency does not match the provided string will be omitted from the results. | | `filters__team__ids` | array | No | An array of team IDs. Only incidents related to these teams will be included in the results. If omitted, all teams the requestor has access to will be included in the results. | | `filters__service__ids` | array | No | An array of service IDs. Only incidents related to these services will be included in the results. If omitted, all services the requestor has access to will be included in the results. | | `filters__priority__ids` | array | No | An array of priority IDs. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__priority__names` | array | No | An array of user-defined priority names. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__created__at__end` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at greater than or equal to this value will be omitted from the results. The maximum supported time range in conjunction with created_at_start is one year. | | `filters__pd__advance__used` | boolean | No | If true, only incidents where PD Advance was used will be included in the results, and vice versa. If omitted, all incidents will be included. | | `filters__created__at__start` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at less than this value will be omitted from the results. The maximum supported time range in conjunction with created_at_end is one year. | | `filters__min__ackowledgements` | integer | No | An integer that sets the requirement for the minimum number of acknowledgements to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 acknowledgement. If no value is provided, all incidents will be included. | | `filters__escalation__policy__ids` | array | No | An array of escalation policy IDs. Only incidents related to these escalation policies will be included in the results. If omitted, all escalation policies the requestor has access to will be included in the results. | | `filters__min__manual__escalations` | integer | No | An integer that sets the requirement for the minimum number of manual escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 manual escalation. If no value is provided, all incidents will be included. | | `filters__min__timeout__escalations` | integer | No | An integer that sets the requirement for the minimum number of timeout escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 timeout escalation. If no value is provided, all incidents will be included. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Aggregate incident metrics with filters **Slug:** `PAGERDUTY_AGGREGATE_INCIDENT_METRICS_WITH_FILTERS` Retrieves and aggregates metrics for incidents across all services in PagerDuty. This endpoint allows for extensive filtering and customization of incident data, enabling detailed analysis of operational performance. It's particularly useful for generating reports, identifying trends, and assessing incident management efficiency over specified time periods. The endpoint supports various filtering criteria, time zone adjustments, and aggregation options, making it a powerful tool for both high-level overviews and granular incident analytics. However, users should be aware of the complexity of the filtering options and ensure they provide accurate parameters to obtain relevant data. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `order` | string ("asc" | "desc") | No | The order in which the results were sorted; asc for ascending, desc for descending. | | `order_by` | string | No | The column that was used for ordering the results. | | `time_zone` | string | No | The time zone to use for the results and grouping. Must be in tzdata format. See list of accepted values [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). | | `aggregate_unit` | string ("day" | "week" | "month") | No | The time unit to aggregate metrics by. If no value is provided, the metrics will be aggregated for the entire period. | | `filters__major` | boolean | No | A boolean flag including whether results should contain *only* [major incidents](https://support.pagerduty.com/docs/operational-reviews#major-incidents), or exclude major incidents. If no value is provided all incidents will be included. | | `filters__urgency` | string ("high" | "low") | No | Any incidents whose urgency does not match the provided string will be omitted from the results. | | `filters__team__ids` | array | No | An array of team IDs. Only incidents related to these teams will be included in the results. If omitted, all teams the requestor has access to will be included in the results. | | `filters__service__ids` | array | No | An array of service IDs. Only incidents related to these services will be included in the results. If omitted, all services the requestor has access to will be included in the results. | | `filters__priority__ids` | array | No | An array of priority IDs. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__priority__names` | array | No | An array of user-defined priority names. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__created__at__end` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at greater than or equal to this value will be omitted from the results. The maximum supported time range in conjunction with created_at_start is one year. | | `filters__pd__advance__used` | boolean | No | If true, only incidents where PD Advance was used will be included in the results, and vice versa. If omitted, all incidents will be included. | | `filters__created__at__start` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at less than this value will be omitted from the results. The maximum supported time range in conjunction with created_at_end is one year. | | `filters__min__ackowledgements` | integer | No | An integer that sets the requirement for the minimum number of acknowledgements to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 acknowledgement. If no value is provided, all incidents will be included. | | `filters__escalation__policy__ids` | array | No | An array of escalation policy IDs. Only incidents related to these escalation policies will be included in the results. If omitted, all escalation policies the requestor has access to will be included in the results. | | `filters__min__manual__escalations` | integer | No | An integer that sets the requirement for the minimum number of manual escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 manual escalation. If no value is provided, all incidents will be included. | | `filters__min__timeout__escalations` | integer | No | An integer that sets the requirement for the minimum number of timeout escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 timeout escalation. If no value is provided, all incidents will be included. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Associate service dependencies **Slug:** `PAGERDUTY_ASSOCIATE_SERVICE_DEPENDENCIES` Associates multiple service dependencies in PagerDuty, allowing you to define relationships between supporting and dependent services. This endpoint is used to establish a hierarchical structure of services, which is crucial for effective incident management and impact analysis. It enables you to create multiple dependencies in a single API call, improving efficiency when setting up complex service relationships. Use this endpoint when you need to define or update the dependency structure of your services in PagerDuty, such as during initial setup, service restructuring, or when adding new services to your incident management workflow. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `relationships` | array | No | List of all service dependencies to be created. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Associate team with automation action **Slug:** `PAGERDUTY_ASSOCIATE_TEAM_WITH_AUTOMATION_ACTION` This endpoint associates a specific team with an automation action in PagerDuty. It allows you to link a team to an automated workflow, enabling better organization and management of automation actions within your incident response processes. Use this endpoint when you need to assign responsibility for an automation action to a particular team or when restructuring your automation workflows. The association helps in tracking, auditing, and managing permissions for automation actions across different teams in your organization. Note that this endpoint only creates the association; it does not create new teams or automation actions. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the automation action to associate the team with. | | `team` | object | Yes | The team reference object containing the team ID to associate. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Audit escalation policy records **Slug:** `PAGERDUTY_AUDIT_ESCALATION_POLICY_RECORDS` Retrieves the audit records for a specific escalation policy in PagerDuty. This endpoint allows users to access a detailed history of changes made to the escalation policy, including modifications to escalation rules, associated services, and on-call schedules. It's particularly useful for compliance tracking, troubleshooting, and understanding how the incident response process has been adjusted over time. The audit records provide transparency into who made changes, what was changed, and when the changes occurred, helping teams maintain accountability and optimize their incident management workflows. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `limit` | integer | No | The minimum of the `limit` parameter used in the request or the maximum request size of the API. | | `since` | string | No | The start of the date range over which you want to search. If not specified, defaults to `now() - 24 hours` (past 24 hours) | | `until` | string | No | The end of the date range over which you want to search. If not specified, defaults to `now()`. May not be more than 31 days after `since`. | | `cursor` | string | No | Optional parameter used to request the "next" set of results from an API. The value provided here is most commonly obtained from the `next_cursor` field of the previous request. When no value is provided, the request starts at the beginning of the result set. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Convert service rule by id **Slug:** `PAGERDUTY_CONVERT_SERVICE_RULE_BY_ID` Converts a service's Event Rules to Event Orchestration rules. This migration endpoint automatically converts Service Event Rules to the newer Event Orchestration format, identically re-creating existing rules while retaining the same behavior. Note: Event Rules reached end-of-life in January 2025. This endpoint migrates from legacy Event Rules to Event Orchestration. Important: Conversion does NOT automatically enable Event Orchestration. You must manually enable it in the service Settings or via API for rules to take effect. Safe to run multiple times - returns existing orchestration URL if already converted. Works even when service has no event rules (returns success with orchestration URL). #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the PagerDuty service whose event rules will be converted to Event Orchestration rules. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Count paused incident reports **Slug:** `PAGERDUTY_COUNT_PAUSED_INCIDENT_REPORTS` Retrieves the count of paused incident reports in the PagerDuty system. This endpoint is part of PagerDuty's Incident Management and Analytics features, providing a quick way to quantify the number of incidents that are currently in a paused state. It's particularly useful for generating high-level analytics, tracking incident management efficiency, and identifying trends in incident handling. The endpoint returns a simple count, making it ideal for dashboard displays or periodic system status checks. It should be used when a rapid overview of paused incidents is needed, but it won't provide detailed information about individual incidents. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `since` | string | No | The start of the date range over which you want to search, in ISO 8601 format (e.g., '2024-01-01T00:00:00Z'). | | `until` | string | No | The end of the date range over which you want to search, in ISO 8601 format (e.g., '2024-12-31T23:59:59Z'). | | `service_id` | string | No | Specifies a filter to limit the scope of reporting to a particular service. Provide the service ID. | | `suspended_by` | string | No | Specifies a filter to scope the response to either alerts suspended by Auto Pause or Event Rules. Valid values: 'auto_pause' (alerts paused by Auto-Pause feature), 'rules' (alerts paused by Event Rules). If not specified, returns counts for all paused incidents regardless of suspension method. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create a custom field for an incident type **Slug:** `PAGERDUTY_CREATE_A_CUSTOM_FIELD_FOR_AN_INCIDENT_TYPE` Create a Custom Field for an Incident Type. Custom Fields (CF) are a feature which will allow customers to extend Incidents with their own custom data, to provide additional context and support features such as customized filtering, search and analytics. Custom Fields can be applied to different incident types. > ### Early Access > This endpoint is in Early Access and may change at any time. You must pass in the X-EARLY-ACCESS header to access it. Scoped OAuth requires: `custom_fields.write` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field__name` | string | No | The name of the custom field. | | `field__enabled` | boolean | No | Whether the custom field is enabled. | | `type_id_or_name` | string | Yes | The ID or name of the Incident Type. | | `field__data__type` | string | No | The data type of the custom field. | | `field__description` | string | No | The description of the custom field. | | `field__field__type` | string ("single_value" | "single_value_fixed" | "multi_value" | "multi_value_fixed") | No | The field type of the custom field. | | `field__display__name` | string | No | The display name of the Incident Type. | | `field__default__value` | string | No | The default value of the custom field. | | `field__field__options` | array | No | The options for the custom field. Can only be applied to fields with a type of multi_value or multi_value_fixed. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create a field option for a custom field **Slug:** `PAGERDUTY_CREATE_A_FIELD_OPTION_FOR_A_CUSTOM_FIELD` Creates a new field option for a custom field on an incident type. Field options represent the allowed values for multi-value or dropdown custom fields. Before using this action: 1. You need a valid incident type ID or name (use LIST_INCIDENT_TYPES to find one) 2. The incident type must have a custom field already created (use CREATE_A_CUSTOM_FIELD_FOR_AN_INCIDENT_TYPE) 3. The custom field should be of type 'multi_value' or 'multi_value_fixed' to support multiple options Use this action to add selectable options to custom fields, enabling users to choose from predefined values when categorizing or tagging incidents. Note: This is an Early Access endpoint that requires the X-EARLY-ACCESS header and the 'custom_fields.write' scope. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field_id` | string | Yes | The ID of the field. | | `type_id_or_name` | string | Yes | The ID or name of the Incident Type. | | `field__option__data__value` | string | Yes | The value of the Field Option for the Custom Field. This is the actual option text that users can select. | | `field__option__data__data__type` | string | Yes | The data type of the Field Option for the Custom Field. Must be 'string' for text values. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create and manage custom incident fields **Slug:** `PAGERDUTY_CREATE_AND_MANAGE_CUSTOM_INCIDENT_FIELDS` Creates a new custom field for incidents in PagerDuty. This endpoint allows you to define additional data points to be associated with incidents, enhancing incident management and reporting capabilities. Custom fields can be used to store various types of information such as environment, severity, or any other relevant metadata. The field can be configured with different data types and value constraints, allowing for flexible and structured data capture. Use this endpoint when you need to extend the incident data model with organization-specific information. Note that once created, certain properties of a custom field cannot be changed, so careful planning of field structure is important. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field__name` | string | Yes | The name of the custom field. | | `field__data__type` | string ("string" | "integer" | "float" | "boolean" | "datetime" | "url") | Yes | The data type of the custom field (string, integer, float, boolean, datetime, url). | | `field__description` | string | No | A description of the custom field and its purpose. | | `field__display__name` | string | Yes | The display name shown in the PagerDuty UI. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create an incident type **Slug:** `PAGERDUTY_CREATE_AN_INCIDENT_TYPE` Create a new incident type. Incident Types are a feature which will allow customers to categorize incidents, such as a security incident, a major incident, or a fraud incident. > ### Early Access > This endpoint is in Early Access and may change at any time. You must pass in the X-EARLY-ACCESS header to access it. For more information see the [API Concepts Document](../../api-reference/ZG9jOjI3NDc5Nzc-api-concepts#incidentType) Scoped OAuth requires: `incident_types.write` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `incident__type__name` | string | No | The name of the Incident Type. Usage of the suffix `_default` is prohibited. This cannot be changed once the incident type has been created. | | `incident__type__enabled` | boolean | No | Whether the Incident Type is enabled. Defaults to true if not provided. | | `incident__type__description` | string | No | The description of the Incident Type. | | `incident__type__parent__type` | string | No | The parent type of the Incident Type. Either name or id of the parent type can be used. | | `incident__type__display__name` | string | No | The display name of the Incident Type. Usage of the prefix `PD`, `PagerDuty`, `Default` is prohibited. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create a ruleset **Slug:** `PAGERDUTY_CREATE_A_RULESET` Creates a new Ruleset in PagerDuty for managing incident routing and notification rules. This endpoint allows you to define a named set of rules that determine how incidents are processed and directed to specific teams or users. It's particularly useful when setting up or modifying your incident management workflow. The created Ruleset can be global, affecting all incoming incidents, or assigned to a specific team for more targeted incident routing. Note that while you can create the Ruleset structure with this call, the actual rules within the Ruleset must be added separately using other API endpoints. #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create incident workflow trigger **Slug:** `PAGERDUTY_CREATE_A_TRIGGER` Creates a new incident workflow trigger in PagerDuty. Triggers define when and how incident workflows are activated - either automatically based on conditions or manually by responders. Trigger types: 'manual' (started by responders) or 'conditional' (fires when conditions are met, e.g., "incident.priority matches 'P1'"). Conditional triggers require a PCL condition string. Specify either a services list or subscribed_to_all_services (not both). Manual triggers support permission restrictions. Requires incident_workflows.write OAuth scope. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `trigger` | object | Yes | The trigger configuration object containing type, workflow ID, and other settings | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create automation runner endpoint **Slug:** `PAGERDUTY_CREATE_AUTOMATION_RUNNER_ENDPOINT` Creates a new Runbook Automation runner in PagerDuty's Automation Actions. A runner is the execution engine that invokes automation actions. Only 'runbook' type runners can be created via API. Required fields: runner_type ('runbook'), name (max 255 chars), description (max 1024 chars), runbook_base_uri (your Runbook instance subdomain), and runbook_api_key (User API token from Runbook). Use this to connect a Runbook Automation server to PagerDuty for executing automation actions during incidents. Requires a subscription with Automation Actions capabilities. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `runner` | string | Yes | Runner configuration object containing runner_type, name, description, runbook_base_uri, and runbook_api_key | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create business service **Slug:** `PAGERDUTY_CREATE_BUSINESS_SERVICE` This endpoint creates a new Business Service in PagerDuty, which represents a specific service or application that can be monitored and managed within the incident management platform. It allows you to define essential properties of the service, including its name, description, point of contact, and the team responsible for it. Use this endpoint when you need to add a new service to your PagerDuty account for monitoring and incident management. The created Business Service can be later associated with technical services, incidents, and escalation policies. Note that this endpoint only creates the Business Service; additional configuration may be required to set up monitoring and alerting for the service. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `business__service__name` | string | No | The name of the Business Service. | | `business__service__team__id` | string | No | The ID of the PagerDuty team that owns this Business Service. Use this to associate the business service with a specific team in your organization. | | `business__service__description` | string | No | The description of the Business Service. | | `business__service__point__of__contact` | string | No | The point of contact for the Business Service. This can be an email address, phone number, or other contact information for the person or team responsible for this service. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create escalation policy **Slug:** `PAGERDUTY_CREATE_ESCALATION_POLICY` Creates a new escalation policy in PagerDuty, defining how incidents are escalated to different responders or teams. This endpoint allows you to set up a structured response plan for managing incidents, including escalation rules, targets, and associated services or teams. Use this when setting up or modifying incident management workflows. The created policy determines the sequence of notifications and assignments for unacknowledged incidents. Note that while you can create the policy structure, actual service associations are read-only and must be managed separately. Only one team can be associated with a policy, and the account must have the 'teams' ability to use this feature. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `escalation_policy` | object | Yes | The escalation policy object to create | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create event orchestration **Slug:** `PAGERDUTY_CREATE_EVENT_ORCHESTRATION` Creates a new Event Orchestration in PagerDuty, which defines how incoming events are processed and routed to appropriate services. This endpoint allows you to set up a configuration that manages the flow of events from various integrations, ensuring efficient incident handling. Use this when you need to establish a new set of rules for event routing, especially when introducing new services or reorganizing your incident management workflow. The created Orchestration can later be associated with specific integrations using their routing keys. Note that while you can create the Orchestration structure, the actual integrations and routing details are managed separately and will be populated as read-only information once configured. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `orchestration__name` | string | Yes | Name of the Event Orchestration (required). This will be displayed in the PagerDuty interface. | | `orchestration__team__id` | string | No | The ID of the team that owns this Event Orchestration (optional). If not specified, only admins will have access to this orchestration. | | `orchestration__description` | string | No | A human-friendly description of this Event Orchestration's purpose (optional). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create event rule in ruleset **Slug:** `PAGERDUTY_CREATE_EVENT_RULE_IN_RULESET` Creates a new Event Rule within a specified Ruleset in PagerDuty's incident management system. This endpoint allows you to define complex conditions for event matching and specify actions to be taken when an event meets those conditions. Use this to automate incident response, customize alert routing, and fine-tune event processing based on specific criteria. The created rule becomes part of the Ruleset's evaluation sequence, affecting how incoming events are processed and managed. **DEPRECATION WARNING**: Rulesets and Event Rules reached end-of-life on January 31, 2025. While the API still supports accessing and modifying existing rulesets/rules, creating new rulesets is disabled. PagerDuty strongly recommends migrating to Event Orchestration for improved UI, advanced conditions, rule nesting, and better API/Terraform support. This action only works with pre-existing rulesets created before the EOL date. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the ruleset to create the event rule in. | | `rule` | object | No | The event rule configuration object. This object defines how incoming events should be processed. It can include: 'conditions' (matching criteria with operator and subconditions), 'actions' (what to do when conditions match - route, annotate, severity, priority, suppress, extract, etc.), 'position' (integer order in ruleset), 'disabled' (boolean to disable rule), 'time_frame' (scheduling with active_between or scheduled_weekly), and 'variables' (data extractions from event payload). Example: {"conditions": {"operator": "and", "subconditions": [{"operator": "contains", "parameter": {"path": "summary", "value": "error"}}]}, "actions": {"route": {"value": "SERVICE_ID"}, "severity": {"value": "error"}}}. Note: minimal rule would be {"actions": {"route": {"value": "SERVICE_ID"}}}. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create extension object **Slug:** `PAGERDUTY_CREATE_EXTENSION_OBJECT` Creates a new extension in PagerDuty, allowing for additional functionality or integrations to be added to your services. This endpoint is used to set up webhooks, custom integrations, or other specific features that enhance the capabilities of your PagerDuty account. The extension is defined by its name, associated services, and a specific extension schema that determines its behavior. Use this endpoint when you need to automate the creation of extensions, such as setting up multiple webhooks or implementing custom workflows. It's particularly useful for large-scale deployments or when programmatically managing your PagerDuty configuration. Note that the extension can be temporarily disabled by PagerDuty if issues arise, such as repeated rejections from a webhook server. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `extension` | object | Yes | The extension object to create. Must include 'name', 'extension_schema' (object with 'id' and 'type' fields), and 'extension_objects' (array of service references). Optional fields include 'endpoint_url' (required for some schemas like Generic V2 Webhook), 'config' (JSON string for extension configuration), and 'type'. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create handoff notification rule **Slug:** `PAGERDUTY_CREATE_HANDOFF_NOTIFICATION_RULE` Creates a new on-call handoff notification rule for a specific user in PagerDuty. This endpoint allows you to set up automated notifications for when a user is about to start or end their on-call shift. It defines how and when the user should be notified about upcoming handoffs, helping to ensure smooth transitions between on-call periods. Use this when you need to establish or modify the way a user is informed about their on-call responsibilities. The rule can be set for incoming shifts, outgoing shifts, or both, and can use various contact methods like email, phone, push notifications, or SMS. Note that this endpoint creates a new rule and does not modify existing ones. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user for whom to create the handoff notification rule. | | `oncall__handoff__notification__rule__id` | string | No | The ID of the handoff notification rule. This is typically auto-generated by PagerDuty and should be omitted when creating a new rule. | | `oncall__handoff__notification__rule__handoff__type` | string ("both" | "oncall" | "offcall") | Yes | The type of handoff for which to send notifications. Must be one of: 'oncall' (notify when going on-call), 'offcall' (notify when going off-call), or 'both' (notify for both). | | `oncall__handoff__notification__rule__contact__method` | object | Yes | The contact method to use for this notification rule. Must be an object with 'id' and 'type' fields. The 'id' should be a valid contact method ID for this user (obtainable via the retrieve_user_contact_methods_via_id action). The 'type' must be one of: 'email_contact_method', 'sms_contact_method', 'phone_contact_method', 'push_notification_contact_method', 'slack_contact_method', or 'whatsapp_contact_method'. Example: {'id': 'PXXXXXX', 'type': 'email_contact_method'} | | `oncall__handoff__notification__rule__notify__advance__minutes` | integer | No | The number of minutes before the handoff when the notification should be sent. Must be between 0 and 2880 (48 hours). Default is 0 (at the time of handoff). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create incident field option **Slug:** `PAGERDUTY_CREATE_INCIDENT_FIELD_OPTION` Creates a new field option for a specific custom field in PagerDuty's incident management system. This endpoint allows you to add predefined options to custom fields, enhancing the ability to categorize and filter incidents with consistent, structured data. Use this when you need to expand the list of selectable values for a string-type custom field. The new option becomes immediately available for selection when updating or creating incidents. Note that this operation is specific to custom fields of type 'string' and cannot be used for other data types. Ensure that the field_id in the URL corresponds to an existing custom field in your PagerDuty account. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field_id` | string | Yes | The ID of the field. | | `field__option__data__value` | string | Yes | The value of the Field Option for the Custom Field. This is the actual option text that users can select when filling in the custom field. | | `field__option__data__data__type` | string | Yes | The data type of the Field Option for the Custom Field. Must be 'field_option_string' for string-type custom fields. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create incident record **Slug:** `PAGERDUTY_CREATE_INCIDENT_RECORD` Creates a new incident in PagerDuty with specified details and assignments. Use this endpoint when an event requires immediate attention from on-call teams. It supports comprehensive incident documentation, including priority, urgency, and conference bridge information. The 'incident_key' parameter helps prevent duplicate incidents, crucial for maintaining a clean incident list. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `From` | string | No | Email address of a valid user associated with the PagerDuty account. This is REQUIRED for incident creation. The user must have permissions to create incidents on the specified service. You can use the GET /users/me endpoint to get the current user's email, or provide any valid user email from your account. Example: "user@example.com" | | `incident__type` | string | No | Specifies the type of object being created. Always set to "incident" for incident creation. This field helps ensure API consistency and proper object handling. | | `incident__title` | string | No | A clear, descriptive title for the incident that helps responders quickly understand the issue. Best Practice Format: " - - " Examples: - "Production Database - CPU Usage 95% - Customer Queries Delayed" - "Payment API - 500 Error Rate >5% - Orders Failing" - "Website - SSL Certificate Expiring - Security Risk" | | `incident__urgency` | string | No | Determines the immediacy of notifications and escalations. Options: - high: Immediate notifications, aggressive escalation - low: Respect service"s notification rules, standard escalation Choose based on: - Business impact - Time sensitivity - Service criticality - Customer impact | | `incident__body__type` | string | No | Specifies the type of body content | | `incident__assignments` | array | No | List of users to assign to the incident. Maximum 10 assignees allowed. Important Notes: - Cannot be used with escalation_policy - Users must have access to the service - Assignments override default escalation - Order matters for primary/secondary | | `incident__service__id` | string | No | Unique identifier for the PagerDuty service. Found in service settings or via API. Example: "PSVC123" | | `incident__priority__id` | string | No | Unique identifier for the priority level. Example: "PRIO123" | | `incident__body__details` | string | No | Comprehensive incident details in structured format. Recommended Structure: ``` CURRENT STATUS: [Brief description of current situation] IMPACT: - Business Impact: [Description] - User Impact: [Number of affected users/systems] - Revenue Impact: [If applicable] ACTIONS TAKEN: 1. [Action 1] 2. [Action 2] METRICS: - Error Rate: [Value] - Response Time: [Value] LINKS: - Dashboard: [URL] - Logs: [URL] - Runbook: [URL] ``` | | `incident__incident__key` | string | No | Unique identifier for deduplicating incidents within a service. Best Practice Format: "---" Examples: - "datadog-cpu-alert-prod-db1-1640995200" - "cloudwatch-memory-warning-cache-1640995200" - "synthetic-api-failure-payments-1640995200" Notes: - Must be unique per service - Used to prevent duplicate incidents - Should be consistent and meaningful | | `incident__service__type` | string ("service_reference") | No | Object type identifier. Always "service_reference" for service objects. | | `incident__priority__type` | string | No | Object type for priority reference | | `incident__incident__type__id` | string | No | Unique identifier for incident type | | `incident__incident__type__name` | string ("major_incident" | "security_incident" | "engineering_incident" | "customer_incident") | No | Predefined incident type categories. Used for reporting and analytics. | | `incident__incident__type__type` | string | No | Object type for incident type reference | | `incident__conference__bridge__conference__url` | string | No | Web conference URL. Should be accessible to all responders. | | `incident__conference__bridge__conference__type` | string ("zoom" | "meet" | "teams" | "webex" | "other") | No | Platform used for conference bridge. Helps responders prepare right tools. | | `incident__conference__bridge__conference__number` | string | No | Phone number with access sequence. Format: "+1-555-123-4567,,,,1234#" Commas (,) represent one-second pauses | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create incident workflow **Slug:** `PAGERDUTY_CREATE_INCIDENT_WORKFLOW` This endpoint creates a new Incident Workflow in PagerDuty, allowing users to define a series of automated steps to be executed during incident response. It enables the setup of complex, multi-step processes that can include actions like sending notifications, updating statuses, or triggering other integrated systems. The workflow creation is highly customizable, supporting various action types and nested workflows, making it suitable for diverse incident management scenarios across different team structures and response protocols. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `incident_workflow` | object | Yes | The incident workflow object containing the workflow definition | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create incident workflow instance **Slug:** `PAGERDUTY_CREATE_INCIDENT_WORKFLOW_INSTANCE` Creates a new instance of an incident workflow for a specific incident in PagerDuty. This endpoint allows you to initiate a predefined workflow process for managing and resolving an ongoing incident. It links the workflow instance to a particular incident, enabling automated and standardized incident response procedures. Use this when you need to start a structured response process for a newly created or existing incident. The endpoint is particularly useful for ensuring consistent handling of incidents across your organization and for tracking the progress of incident resolution through defined stages. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident workflow. | | `incident__workflow__instance__incident__id` | string | Yes | The ID of the incident to start the workflow for. | | `incident__workflow__instance__incident__type` | string ("incident_reference") | No | The type of the incident reference. Always 'incident_reference'. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create integration for orchestration **Slug:** `PAGERDUTY_CREATE_INTEGRATION_FOR_ORCHESTRATION` Creates a new integration for an existing event orchestration in PagerDuty. This action adds an integration to an event orchestration, enabling it to receive events from external monitoring tools, alerting systems, or custom applications. Each integration gets a unique routing key for use with the PagerDuty Events API v2. Use cases: Connect monitoring tools (Datadog, New Relic, CloudWatch), set up custom alerting systems, create multiple event sources, or separate event streams by environment. Requirements: Event orchestration ID and a descriptive integration label. Returns: Integration with unique ID, routing key for Events API v2, and label. Note: Max 10 integrations per orchestration. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | | `integration__label` | string | Yes | A descriptive name for the integration (e.g., 'Datadog Monitoring', 'AWS CloudWatch', 'New Relic Alerts'). This label helps identify the integration's purpose and source system. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create integration for service **Slug:** `PAGERDUTY_CREATE_INTEGRATION_FOR_SERVICE` Creates a new integration for a PagerDuty service to enable incident creation from external monitoring tools and systems. Integrations can be either generic (using 'type' parameter) or vendor-specific (using 'vendor' parameter). **Common integration types:** - events_api_v2_inbound_integration: Modern Events API v2 for custom integrations - generic_events_api_inbound_integration: Generic Events API v1 integration - generic_email_inbound_integration: Email-based incident creation **Vendor integrations:** Use the 'vendor' parameter with an ID from the vendors endpoint to create integrations for specific tools like Datadog, AWS CloudWatch, Nagios, New Relic, etc. **Returns:** The created integration object with an integration_key (for API integrations) or integration_email (for email integrations) that can be used to send events to PagerDuty. **Note:** Each integration belongs to exactly one service. Use this action after creating a service to establish monitoring channels. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the service to create the integration for. | | `integration` | object | Yes | The integration object containing configuration details. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create maintenance window object **Slug:** `PAGERDUTY_CREATE_MAINTENANCE_WINDOW_OBJECT` Creates a new maintenance window in PagerDuty, allowing you to schedule periods of planned maintenance for specific services. During a maintenance window, incidents are not created for the affected services, preventing unnecessary alerts and notifications. This endpoint is useful for planning and executing system upgrades, patches, or other maintenance tasks without triggering false alarms. The maintenance window has a defined start and end time, can be associated with multiple services, and optionally linked to specific teams. It's important to note that while incidents are suppressed during the maintenance window, underlying issues are still logged and can be reviewed later if needed. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `maintenance_window` | object | Yes | The maintenance window object to create | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create new schedule layer **Slug:** `PAGERDUTY_CREATE_NEW_SCHEDULE_LAYER` Creates a new on-call schedule in PagerDuty with one or more rotation layers. A schedule defines who is on-call at any given time. Each schedule contains one or more layers that specify rotation patterns, with each layer having: - User assignments (who participates in the rotation) - Rotation timing (how long each person is on-call) - Time zone for the schedule - Optional restrictions (e.g., only active during business hours) Use this action to: - Set up new on-call rotations for incident response - Define daily, weekly, or custom rotation patterns - Create multi-layer schedules (e.g., business hours + after-hours) - Establish coverage schedules for escalation policies The schedule will be available immediately after creation and can be referenced in escalation policies to route incidents to the right people. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `overflow` | boolean | No | Any on-call schedule entries that pass the date range bounds will be truncated at the bounds, unless the parameter `overflow=true` is passed. This parameter defaults to false. For instance, if your schedule is a rotation that changes daily at midnight UTC, and your date range is from `2011-06-01T10:00:00Z` to `2011-06-01T14:00:00Z`: - If you don"t pass the `overflow=true` parameter, you will get one schedule entry returned with a start of `2011-06-01T10:00:00Z` and end of `2011-06-01T14:00:00Z`. - If you do pass the `overflow=true` parameter, you will get one schedule entry returned with a start of `2011-06-01T00:00:00Z` and end of `2011-06-02T00:00:00Z`. | | `schedule` | object | Yes | The schedule object to create with layers, users, and time configuration | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create new service **Slug:** `PAGERDUTY_CREATE_NEW_SERVICE` Creates a new service in PagerDuty, which is a key component for managing incidents and alerts. This endpoint allows you to set up a service with various configurations including escalation policies, incident urgency rules, support hours, and alert grouping parameters. Use this when you need to add a new monitored service to your PagerDuty account, such as a new application, infrastructure component, or business process. The created service will be used as a target for incoming alerts and incidents, helping to organize and streamline your incident management process. Note that some advanced features like intelligent alert grouping may depend on your PagerDuty plan. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `service` | object | Yes | The service object to create | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create new tag in system **Slug:** `PAGERDUTY_CREATE_NEW_TAG_IN_SYSTEM` Creates a new tag in PagerDuty for labeling and categorizing entities. This endpoint allows users to add a custom label to their PagerDuty account, which can be used to organize and filter various resources such as incidents, services, or teams. The created tag can be subsequently assigned to relevant entities to improve organization and searchability within the PagerDuty platform. Use this endpoint when you need to introduce a new categorization or labeling scheme in your PagerDuty setup. Note that this endpoint only creates the tag; assigning it to specific entities would require separate API calls. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `type` | string | No | The type of the object. Must be "tag". | | `label` | string | Yes | The label/name of the tag to create. This is the primary identifier for the tag. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create new team with details **Slug:** `PAGERDUTY_CREATE_NEW_TEAM_WITH_DETAILS` Creates a new team in PagerDuty for organizing users, incident management, and on-call schedules. Required: team.name (unique team name) Optional: team.description, team.parent (for nested hierarchies), team.default_role Use when setting up departments, project teams, or organizing users with shared incident response responsibilities. After creation, use separate API calls to add members to the team. Examples: - Basic: {"team": {"name": "Platform Team"}} - With details: {"team": {"name": "SRE Team", "description": "Site Reliability Engineering"}} - Nested: {"team": {"name": "Backend API", "parent": "PXXXXXX", "default_role": "responder"}} Note: Requires paid PagerDuty plan with Teams feature enabled. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `team` | object | Yes | The team object containing the details of the team to create. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create new webhook subscription **Slug:** `PAGERDUTY_CREATE_NEW_WEBHOOK_SUBSCRIPTION` Creates a new webhook subscription in PagerDuty to receive specific event notifications. This endpoint allows users to set up automated notifications for various incident-related events, such as triggers, acknowledgments, and resolutions. The webhook can be configured to filter events by service, team, or account-wide, and supports custom HTTP headers for enhanced integration capabilities. Use this when you need to integrate PagerDuty's real-time incident updates with external systems or workflows. Note that the webhook's secret for payload verification is only provided in the initial creation response and cannot be retrieved later. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `webhook__subscription__id` | string | No | Id | | `webhook__subscription__type` | string ("webhook_subscription") | No | The type indicating the schema of the object. | | `webhook__subscription__active` | boolean | No | Determines whether this subscription will produce webhook events. | | `webhook__subscription__events` | array | No | List of incident event types to subscribe to (required). Valid values include: incident.triggered, incident.acknowledged, incident.resolved, incident.escalated, incident.annotated, incident.delegated, incident.priority_updated, incident.reassigned, incident.reopened, incident.unacknowledged, incident.responder.added, incident.responder.replied, incident.status_update_published | | `webhook__subscription__filter__id` | string | No | The ID of the service or team to filter events (required when filter_type is service_reference or team_reference, not needed for account_reference) | | `webhook__subscription__description` | string | No | A short description of the webhook subscription. | | `webhook__subscription__filter__type` | string ("account_reference" | "service_reference" | "team_reference") | No | The scope of events to receive (required). Options: 'account_reference' for all account events, 'service_reference' for specific service events (requires filter_id), 'team_reference' for specific team events (requires filter_id) | | `webhook__subscription__delivery__method__id` | string | No | Id | | `webhook__subscription__delivery__method__url` | string | No | The HTTPS URL endpoint where webhook events will be sent (required). Must be publicly accessible. | | `webhook__subscription__delivery__method__type` | string ("http_delivery_method") | No | Indicates the type of the delivery method. | | `webhook__subscription__delivery__method__secret` | string | No | The secret used to sign webhook payloads. Only provided on the initial create response. | | `webhook__subscription__delivery__method__custom__headers` | array | No | Optional headers to be set on this webhook subscription when sent. The header values are redacted in GET requests, but are not redacted on the webhook when delivered to the webhook"s endpoint. | | `webhook__subscription__delivery__method__temporarily__disabled` | boolean | No | Whether or not this webhook subscription is temporarily disabled. Becomes `true` if the delivery method URL is repeatedly rejected by the server. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create or update status page post **Slug:** `PAGERDUTY_CREATE_OR_UPDATE_STATUS_PAGE_POST` Creates a new post on a PagerDuty Status Page to communicate service status to users. Use this action to publish incident reports (for service disruptions) or maintenance announcements (for scheduled work). Each post includes a title, type, and one or more updates describing the current situation. You can specify which services are impacted, the severity level, whether to notify subscribers, and expected update frequency. For maintenance posts, include start and end times. For incident posts, these times are optional. This action is essential for transparent customer communication during service issues or planned work. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page to create a post on. | | `post__type` | string ("status_page_post") | No | The type identifier for the post object. Must be 'status_page_post'. | | `post__title` | string | No | The title of the status page post. This will be displayed prominently to status page viewers. | | `post__updates` | array | No | A list of status updates to be included with the post. Each update contains a message, impacted services, severity, and notification settings. | | `post__ends__at` | string | No | The end date and time for the maintenance window in ISO 8601 format (e.g., '2026-01-29T13:00:00Z'). Required when post_type is 'maintenance', optional for 'incident' posts. | | `post__post__type` | string ("incident" | "maintenance") | No | The type of post: 'incident' for service disruptions or ongoing issues, or 'maintenance' for scheduled maintenance windows. | | `post__starts__at` | string | No | The start date and time for the maintenance window in ISO 8601 format (e.g., '2026-01-29T12:00:00Z'). Required when post_type is 'maintenance', optional for 'incident' posts. | | `post__status__page__id` | string | No | The ID of the status page. Must match the 'id' path parameter. | | `post__status__page__type` | string | No | The type identifier for the status page object. Should be 'status_page'. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create or update status page postmortem **Slug:** `PAGERDUTY_CREATE_OR_UPDATE_STATUS_PAGE_POSTMORTEM` Creates or updates a postmortem for a specific status page post in PagerDuty. This endpoint allows you to add detailed analysis and insights about an incident after its resolution. The postmortem can include rich-text content and offers the option to notify subscribers. Use this when you need to provide a comprehensive review of an incident, its root causes, and lessons learned. It's particularly useful for maintaining transparency and improving incident response processes. Note that the postmortem is limited to 10,000 characters and is always associated with an existing status page post. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the Status Page. | | `post_id` | string | Yes | The ID of the Status Page Post. | | `postmortem__type` | string ("status_page_post_postmortem") | No | The type of the object - must be 'status_page_post_postmortem'. | | `postmortem__message` | string | Yes | The message content of the Postmortem (supports Rich-Text formatting, max 10,000 characters). | | `postmortem__post__id` | string | Yes | The ID of the Status Page Post to which this postmortem belongs. Should match the post_id path parameter. | | `postmortem__post__type` | string | No | The type of the post object - typically 'status_page_post'. | | `postmortem__notify__subscribers` | boolean | Yes | Whether subscribers of the Status Page should be notified about the Postmortem. Set to true to send notifications, false otherwise. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create response play for incidents **Slug:** `PAGERDUTY_CREATE_RESPONSE_PLAY_FOR_INCIDENTS` Creates a new Response Play in PagerDuty, which is a predefined set of actions to be executed in response to an incident. This endpoint allows you to configure automated responses, including adding subscribers, assigning responders, setting up conference details, and defining how the Response Play can be triggered. Use this when you want to standardize and automate your incident management process, ensuring consistent and efficient responses to different types of incidents. The Response Play can be set to run automatically for specific services or be manually triggered by team members or responders, depending on the configuration. This tool is particularly useful for creating templated responses for common incident types or for implementing best practices across your organization's incident management workflow. #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create schedule overrides configuration **Slug:** `PAGERDUTY_CREATE_SCHEDULE_OVERRIDES_CONFIGURATION` Creates one or more overrides for a specific schedule in PagerDuty. This endpoint allows you to temporarily modify the on-call schedule by assigning different users for specific time periods. It's useful for handling planned absences, shift swaps, or special coverage requirements without permanently altering the regular schedule. The overrides are applied to the schedule identified by the {id} parameter in the endpoint URL. Multiple overrides can be created in a single request, enabling efficient batch modifications to the schedule. Each override specifies a start time, end time, and the user who will be on call during that period. The endpoint should be used when temporary changes to the on-call rotation are needed. It does not modify the underlying schedule configuration. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the schedule to create overrides for. | | `overrides` | array | Yes | A list of override objects to create. Each override specifies a time period and the user who will be on call during that period. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create service event rule **Slug:** `PAGERDUTY_CREATE_SERVICE_EVENT_RULE` Creates a new event rule for a specific service in PagerDuty. This endpoint allows you to define complex conditions and actions for handling incoming events, enabling automated incident management and alert routing. Use this when you need to set up custom logic for processing events, such as setting priorities, annotating incidents, or suppressing alerts based on specific criteria. The rule's position in the evaluation order can be specified, and various time-based conditions can be applied to control when the rule is active. This endpoint is crucial for fine-tuning your incident response workflow and reducing alert noise. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the service. | | `rule` | object | No | The event rule configuration object. Should include 'actions' (with operations like suppress, severity, priority, annotate, etc.), optional 'conditions' (with operator and subconditions for matching events), optional 'time_frame' (for scheduling when the rule is active), optional 'variables' (for extracting data from events), optional 'position' (for rule ordering), and optional 'disabled' (to disable the rule). Example: {'actions': {'suppress': False, 'severity': {'value': 'warning'}}, 'conditions': {'operator': 'and', 'subconditions': [{'operator': 'contains', 'parameters': [{'path': 'payload.summary', 'value': 'error'}]}]}} | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create statuspage subscription **Slug:** `PAGERDUTY_CREATE_STATUS_PAGE_SUBSCRIPTION` Creates a new subscription for a PagerDuty status page. This endpoint allows users to set up notifications for specific status pages or components within those pages. It's used to keep subscribers informed about updates, incidents, or changes to the monitored services. The subscription can be configured for either email or webhook notifications, allowing for flexible integration with various notification systems. This tool should be used when setting up new monitoring or alert systems, or when adding new stakeholders who need to be kept informed about service status. It's particularly useful for DevOps teams, IT managers, or customer support teams who need real-time updates on service health. Note that this endpoint only creates the subscription; it does not manage or trigger the actual notifications. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page to create a subscription for. This is used in the URL path. | | `subscription__type` | string | No | The type of subscription being created. Must be 'status_page_subscription'. | | `subscription__channel` | string ("webhook" | "email") | Yes | The notification channel for the subscription. Must be 'email' or 'webhook'. | | `subscription__contact` | string | Yes | The subscriber's contact information. Must be an email address (for 'email' channel) or webhook URL (for 'webhook' channel). | | `subscription__status__page__id` | string | Yes | The ID of the status page to subscribe to. Must match the '{id}' path parameter. | | `subscription__status__page__type` | string | No | The type reference for the status page. Typically 'status_page_reference'. | | `subscription__subscribable__object__id` | string | Yes | The ID of the entity to subscribe to. For status_page type, this is the status page ID. For status_page_service type, this is the service ID. For status_page_post type, this is the post ID. | | `subscription__subscribable__object__type` | string ("status_page" | "status_page_service" | "status_page_post") | Yes | The type of entity to subscribe to. Options: 'status_page' (entire page), 'status_page_service' (specific service), or 'status_page_post' (specific post). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create status update template **Slug:** `PAGERDUTY_CREATE_STATUS_UPDATE_TEMPLATE` Creates a new status update template in PagerDuty for standardized incident notifications. Templates provide consistent, pre-formatted messages for stakeholder updates across email, SMS, push, and Slack. Supports dynamic variables like {{incident.title}}, {{incident.status}}, etc. Requires PagerDuty Business or Enterprise plan (returns 402 error otherwise). Only 'status_update' template type is currently supported. At minimum, provide a template name. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `template__name` | string | Yes | The name of the template (required). Should be a unique, descriptive name to identify this template. Example: 'Incident Resolution Notification'. | | `template__description` | string | No | Optional description of the template's purpose and usage. Example: 'Template used for notifying stakeholders when incidents are resolved'. | | `template__template__type` | string ("status_update") | No | The type of template. Currently only 'status_update' is supported. Defaults to 'status_update'. | | `template__templated__fields__message` | string | No | Optional short message for SMS, push notifications, Slack, and other channels. Keep concise (under 140 characters recommended). Supports PagerDuty template variables like {{incident.title}}, {{incident.status}}, etc. Example: 'Incident {{incident.title}}: {{incident.status}}' | | `template__templated__fields__email__body` | string | No | Optional HTML-formatted email body for status update notifications. Supports PagerDuty template variables like {{incident.title}}, {{incident.id}}, {{incident.status}}, {{incident.urgency}}, etc. Use standard HTML tags for formatting. Example: '

Incident {{incident.id}}: {{incident.title}} has been updated.

' | | `template__templated__fields__email__subject` | string | No | Optional email subject line for status update notifications. Supports PagerDuty template variables like {{incident.title}}, {{incident.id}}, {{incident.status}}, {{incident.urgency}}, etc. Example: 'Incident Update: {{incident.title}}' | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create user notification rule **Slug:** `PAGERDUTY_CREATE_USER_NOTIFICATION_RULE` Creates a new notification rule for a specific user in PagerDuty. This endpoint allows you to define how and when a user should be notified about assigned incidents. You can specify the delay before notification, the method of contact, and the urgency level of incidents that trigger this rule. This is particularly useful for customizing alert behaviors for different users based on their preferences or role within the organization. The rule created will be associated with the user identified by the provided ID in the URL path. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user. | | `notification__rule__type` | string | No | The type of notification rule. Typically 'assignment_notification_rule'. | | `notification__rule__urgency` | string | Yes | The urgency level that triggers this rule. Must be either 'high' or 'low'. | | `notification__rule__contact__method` | object | Yes | The contact method to use for this notification rule. Must be an object with 'id' and 'type' fields. Example: {'id': 'PXXXXXX', 'type': 'email_contact_method'}. Type must be one of: email_contact_method, phone_contact_method, sms_contact_method, push_notification_contact_method, slack_contact_method, or whatsapp_contact_method. | | `notification__rule__start__delay__in__minutes` | integer | Yes | The delay in minutes before the notification is sent. Must be a non-negative integer. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create user object **Slug:** `PAGERDUTY_CREATE_USER_OBJECT` Creates a new user in the PagerDuty system with the specified attributes. This endpoint should be used when onboarding new team members or adding users to your PagerDuty account. It allows you to set up essential user information, including name, email, role, and time zone preferences. The created user will have default contact methods and notification rules, which can be customized later. Note that some fields like teams, contact methods, and notification rules cannot be set during user creation and must be managed separately. The endpoint requires at minimum a name, email, and user type, with several optional fields for further customization. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `user` | object | Yes | The user object to create | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create user status update notification rule **Slug:** `PAGERDUTY_CREATE_USER_STATUS_UPDATE_NOTIFICATION_RULE` Creates a new status update notification rule for a specific user in PagerDuty. This endpoint allows you to define how a user will be notified about incident status updates. It's used to customize notification preferences for individual users, ensuring they receive timely updates through their preferred contact method. The rule specifies which contact method (email, phone, push notification, or SMS) should be used for sending status updates. This is particularly useful for tailoring notification strategies to match users' roles and responsibilities within the incident management process. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user. | | `status__update__notification__rule__contact__method` | object | Yes | The contact method to use for this status update notification rule. Must be an object with 'id' and 'type' fields. Example: {'id': 'PXXXXXX', 'type': 'email_contact_method'}. The type must be one of: email_contact_method, phone_contact_method, sms_contact_method, or push_notification_contact_method. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Create workflow integration connection **Slug:** `PAGERDUTY_CREATE_WORKFLOW_INTEGRATION_CONNECTION` Create a new Workflow Integration Connection. Scoped OAuth requires: `workflow_integrations:connections.write` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | No | The ID of the connection | | `name` | string | Yes | The name given to the connection | | `type` | string | No | The type of the connection | | `teams` | array | No | The teams whose managers are allowed to use or edit this connection | | `scopes` | array | No | Scopes | | `is_default` | boolean | No | Whether or not this connection is the default connection for this integration | | `external_id` | string | No | The ID of the external system that this connection is used to connect to | | `service_url` | string | No | The URL of the service that this connection is associated with | | `integration_id` | string | Yes | The ID of the Workflow Integration | | `external_id_label` | string | No | The label of the external system that this connection is used to connect to | | `health__is__healthy` | boolean | No | Whether or not the connection is healthy | | `health__health__message` | string | No | A message describing the health of the connection | | `health__last__checked__at` | string | No | The timestamp of the last health check | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete account subscription by id **Slug:** `PAGERDUTY_DELETE_ACCOUNT_SUBSCRIPTION_BY_ID` Deletes the account subscription associated with a specific business service in PagerDuty. This endpoint is used to terminate the subscription or billing relationship between a business service and the account. It should be used when you need to discontinue the subscription for a particular business service, such as when the service is no longer needed or when restructuring your PagerDuty setup. This action is irreversible, so it should be used with caution. The endpoint does not return any specific data upon successful deletion, likely providing only a success status code. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the business service whose account subscription should be deleted. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete a custom field for an incident type **Slug:** `PAGERDUTY_DELETE_A_CUSTOM_FIELD_FOR_AN_INCIDENT_TYPE` Deletes a custom field from an incident type. This permanently removes the field definition and associated options, but does not affect historical data on existing incidents. Prerequisites: 1. Valid incident type ID or name (use LIST_INCIDENT_TYPES) 2. Custom field on that incident type (use LIST_INCIDENT_TYPE_CUSTOM_FIELDS) 3. API token with 'custom_fields.write' scope Note: Early Access endpoint requiring X-EARLY-ACCESS header with 'analytics-v2'. Use case: Remove deprecated fields or clean up test fields. Scoped OAuth requires: `custom_fields.write` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field_id` | string | Yes | The ID of the custom field to delete from this incident type. Custom fields extend incidents with additional data. Use LIST_INCIDENT_TYPE_CUSTOM_FIELDS to find custom fields for an incident type. | | `type_id_or_name` | string | Yes | The ID or name of the Incident Type. You can use the incident type ID (e.g., 'P5VNOVL') or the incident type name (e.g., 'incident_default'). Use LIST_INCIDENT_TYPES to find available incident types. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete addon by id **Slug:** `PAGERDUTY_DELETE_ADDON_BY_ID` Deletes a specific add-on from the PagerDuty account using its unique identifier. This endpoint should be used when you want to remove an integration or extension that is no longer needed or active in your PagerDuty setup. It's important to note that this action is irreversible, and once an add-on is deleted, it cannot be recovered without re-adding it. Use this endpoint with caution, as removing an add-on may impact any automated workflows or integrations that depend on it. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the add-on to delete. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete a field option for a custom field **Slug:** `PAGERDUTY_DELETE_A_FIELD_OPTION_FOR_A_CUSTOM_FIELD` Deletes a specific field option from a custom field on an incident type. Field options represent the allowed values for multi-value or dropdown custom fields. This action permanently removes a field option. If incidents are using this field option value, the behavior depends on PagerDuty's configuration for handling deleted options. Prerequisites: 1. A valid incident type ID or name (use LIST_INCIDENT_TYPES to find one) 2. A custom field on that incident type (use LIST_INCIDENT_TYPE_CUSTOM_FIELDS) 3. A field option on that custom field (use LIST_FIELD_OPTIONS_ON_A_CUSTOM_FIELD) Note: This is an Early Access endpoint that requires the X-EARLY-ACCESS header with 'analytics-v2' and the 'custom_fields.write' scope. Example use case: Remove an obsolete option from a severity or category dropdown field after it's no longer needed for incident classification. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field_id` | string | Yes | The ID of the custom field on this incident type. Custom fields extend incidents with additional data. Use LIST_INCIDENT_TYPE_CUSTOM_FIELDS to find custom fields for an incident type. | | `field_option_id` | string | Yes | The ID of the field option to delete. Field options are the allowed values for multi-value custom fields. Use LIST_FIELD_OPTIONS_ON_A_CUSTOM_FIELD to find field options for a custom field. | | `type_id_or_name` | string | Yes | The ID or name of the Incident Type. You can use the incident type ID (e.g., 'P5VNOVL') or the incident type name (e.g., 'incident_default'). Use LIST_INCIDENT_TYPES to find available incident types. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete alert grouping setting **Slug:** `PAGERDUTY_DELETE_ALERT_GROUPING_SETTING` This endpoint allows you to delete specific alert grouping settings in PagerDuty. It is used to remove outdated or unnecessary configurations that determine how alerts are grouped into incidents. The deletion is permanent and cannot be undone, so it should be used with caution. This operation is particularly useful when updating your incident management strategy or cleaning up unused configurations to maintain an efficient alert grouping system. Note that deleting these settings may affect how future alerts are grouped, potentially impacting your team's incident response workflow. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete all oauth delegations **Slug:** `PAGERDUTY_DELETE_ALL_OAUTH_DELEGATIONS` Delete all OAuth delegations for a user based on the specified type. An OAuth delegation represents an instance of a user or account's authorization to an app (via OAuth) to access their PagerDuty account. Common apps include the PagerDuty mobile app, Slack, Microsoft Teams, and third-party apps. Deleting an OAuth delegation will revoke that instance of an app's access to that user or account. To grant access again, reauthorization/reauthentication may be required. Currently, this endpoint only supports deleting mobile app OAuth delegations for a given user. This is equivalent to signing users out of the PagerDuty mobile app. The deletion is processed synchronously and takes effect immediately. Scoped OAuth requires: `oauth_delegations.write` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `type` | string ("mobile") | Yes | The type of OAuth delegations to delete. Currently only 'mobile' is supported, which signs users out of the PagerDuty mobile app. | | `user_id` | string | Yes | The PagerDuty user ID for whom to delete OAuth delegations (e.g., 'PUVQN44'). You can retrieve user IDs using the list users action. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete automation action by id **Slug:** `PAGERDUTY_DELETE_AUTOMATION_ACTION_BY_ID` Deletes a specific Automation Action from the PagerDuty system. This endpoint is used to permanently remove an Automation Action, which includes any associated scripts or jobs in Runbook Automation. It should be used when an Automation Action is no longer needed or has become obsolete. Once deleted, the action cannot be recovered, so use this endpoint with caution. This operation is typically performed by administrators or users with appropriate permissions to manage Automation Actions. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete automation action service by id **Slug:** `PAGERDUTY_DELETE_AUTOMATION_ACTION_SERVICE_BY_ID` This endpoint removes a specific automation action from a particular service in PagerDuty. It is used to disassociate an automated workflow or action from a service, effectively stopping that action from being triggered for incidents related to the specified service. This operation is useful when you need to update your incident management workflow or when an automated action is no longer relevant for a specific service. It's important to note that this endpoint only removes the association between the action and the service; it does not delete the automation action itself from the system. Use this endpoint with caution, as removing an automation action from a service will immediately affect the incident response process for that service. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `service_id` | string | Yes | The service ID | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete automation actions runner by id **Slug:** `PAGERDUTY_DELETE_AUTOMATION_ACTIONS_RUNNER_BY_ID` Permanently deletes an automation actions runner from PagerDuty. Automation runners execute automated tasks and workflows during incident response. Use this when a runner is no longer needed or needs replacement. WARNING: Deletion is irreversible and will affect all automation actions and schedules using this runner. Requires Automation Actions feature subscription. To use: First obtain the runner ID via list_automation_actions_runners or get_automation_action_runner_by_id, then call this endpoint with that ID. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the automation actions runner to delete. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete business service by id **Slug:** `PAGERDUTY_DELETE_BUSINESS_SERVICE_BY_ID` Deletes a specific business service from the PagerDuty system. This endpoint should be used when you want to permanently remove a business service that is no longer needed or relevant to your organization's incident management structure. It's important to note that this action is irreversible and will remove all associations between the deleted business service and any technical services or incidents. Use this endpoint with caution, as it may impact reporting and historical data related to the deleted business service. Before deletion, ensure that no active incidents or dependencies rely on this business service to avoid disruptions in your incident management workflow. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete business service priority thresholds **Slug:** `PAGERDUTY_DELETE_BUSINESS_SERVICE_PRIORITY_THRESHOLDS` Deletes the account-level global priority threshold for business services in PagerDuty. This endpoint removes the configured priority threshold that determines the minimum incident priority level required for incidents to impact business services. When a global threshold is set, only incidents at or above that priority level will affect business services. Use this action to remove the global threshold entirely, allowing incidents of any priority to impact business services (or reverting to default behavior). This operation is idempotent - it can be called even when no threshold is currently set. The action does not delete business services themselves, only the global priority threshold configuration. Note that this affects all business services across the account. #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete cache variable for event **Slug:** `PAGERDUTY_DELETE_CACHE_VARIABLE_FOR_EVENT` Deletes a specific cache variable associated with an event orchestration in PagerDuty. This endpoint is used to remove temporary data storage that was previously set up for use in event orchestration workflows. It should be used when you need to clean up or remove outdated cache variables that are no longer needed in your event management process. This operation is idempotent - attempting to delete a cache variable that doesn't exist will return a successful response. The endpoint requires both the event orchestration ID and the specific cache variable ID to ensure precise removal of the intended data. Requirements: - Event Intelligence/Digital Operations plan OR PagerDuty AIOps add-on - Advanced Event Orchestration pricing tier - API token with event_orchestrations:write scope - User with Team Manager-level permissions or above #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier (UUID) of the Event Orchestration that contains the cache variable to delete. | | `cache_variable_id` | string | Yes | The unique identifier (UUID) of the Cache Variable to delete from the Event Orchestration. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete cache variable from service **Slug:** `PAGERDUTY_DELETE_CACHE_VARIABLE_FROM_SERVICE` Deletes a cache variable from a service's event orchestration. Cache variables store temporary data used in event orchestration workflows. This action permanently removes the specified cache variable. Returns HTTP 204 No Content on successful deletion. Use this when cleaning up obsolete cache variables or freeing resources. Note: This action cannot be undone. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `service_id` | string | Yes | The service ID | | `cache_variable_id` | string | Yes | The ID of a Cache Variable. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete custom field by field id **Slug:** `PAGERDUTY_DELETE_CUSTOM_FIELD_BY_FIELD_ID` Deletes a specific custom field from incidents in PagerDuty. This endpoint allows users to remove a custom field that is no longer needed or relevant for incident management. It should be used when you want to permanently delete a custom field from all incidents, both existing and future. The operation is irreversible, so caution should be exercised when using this endpoint. It's important to note that this action will remove the specified custom field and its associated data from all incidents, which could impact reporting and analysis based on that field. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field_id` | string | Yes | The unique identifier of the custom field to delete. This is returned when creating or listing custom fields. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete escalation policy by id **Slug:** `PAGERDUTY_DELETE_ESCALATION_POLICY_BY_ID` Permanently removes a specific escalation policy from the PagerDuty system. This endpoint should be used when an escalation policy is no longer needed or has become obsolete. Once deleted, the escalation policy cannot be recovered, and any services or incidents associated with it will need to be reassigned. Exercise caution when using this endpoint, as it will impact incident routing and may affect your team's ability to respond to alerts if not properly managed. It's recommended to review and update any dependent services before deleting an escalation policy. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete event by id **Slug:** `PAGERDUTY_DELETE_EVENT_BY_ID` Deletes a specific Event Orchestration from the PagerDuty system. This endpoint should be used when you want to permanently remove an Event Orchestration configuration, including all its associated rules and routing logic. It's important to note that this action is irreversible, and once an Event Orchestration is deleted, it cannot be recovered. Before using this endpoint, ensure that the Event Orchestration is no longer needed and that its deletion won't disrupt any critical event routing or automation processes in your PagerDuty setup. This endpoint is particularly useful during cleanup operations or when restructuring your event management workflow. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete extension by id **Slug:** `PAGERDUTY_DELETE_EXTENSION_BY_ID` Deletes a specific extension from the PagerDuty service. This endpoint should be used when you want to remove an additional feature or integration that has been previously added to your PagerDuty account. It's particularly useful for cleaning up obsolete integrations or disabling unwanted functionalities. Note that deleting an extension is permanent and cannot be undone, so use this endpoint with caution. This operation doesn't affect the core PagerDuty service, only the specified extension. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete field option **Slug:** `PAGERDUTY_DELETE_FIELD_OPTION` Permanently deletes a field option from a custom incident field. For example, removes "Medium" from a Priority field with options "Critical", "High", "Medium", "Low". **Prerequisites:** Use PAGERDUTY_RETRIEVE_INCIDENT_CUSTOM_FIELDS with include='field_options' to get valid field_id and field_option_id values. Requires OAuth scope: custom_fields.write **Warning:** This is IRREVERSIBLE and may impact existing incidents, reports, and automations that use this option value. Returns HTTP 204 No Content on success. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field_id` | string | Yes | The ID of the custom field containing the option to delete. Custom fields are additional data points you can add to incidents for categorization, filtering, and reporting. Example: 'P4X7Y2Z'. You can retrieve field IDs using PAGERDUTY_RETRIEVE_INCIDENT_CUSTOM_FIELDS. | | `field_option_id` | string | Yes | The ID of the specific field option to delete. Field options are predefined values for a custom field (e.g., 'High', 'Medium', 'Low' for a Priority field). Example: 'POPT123'. WARNING: This operation is destructive and cannot be undone. Deleting a field option may affect existing incidents using this value. You can retrieve field option IDs by calling PAGERDUTY_RETRIEVE_INCIDENT_CUSTOM_FIELDS with include='field_options'. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete incident workflow by id **Slug:** `PAGERDUTY_DELETE_INCIDENT_WORKFLOW_BY_ID` Deletes a specific incident workflow from the PagerDuty system. This endpoint should be used when you want to permanently remove a customized sequence of automated actions and triggers associated with incident management. It's important to note that this action is irreversible, and once deleted, the workflow cannot be recovered. Use this endpoint with caution, ensuring that the workflow is no longer needed before deletion. This operation helps in maintaining a clean and relevant set of incident workflows, improving overall incident management efficiency. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident workflow to delete. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete incident workflow trigger by id **Slug:** `PAGERDUTY_DELETE_INCIDENT_WORKFLOW_TRIGGER_BY_ID` Deletes a specific trigger associated with an incident workflow in PagerDuty. This endpoint is used to remove an automated trigger that initiates a predefined workflow in response to incidents. It should be used when you need to modify your incident response automation by removing outdated or unnecessary triggers. This operation is permanent and cannot be undone, so it should be used with caution. The endpoint does not return any data upon successful deletion, typically responding with a 204 No Content status. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the incident workflow trigger to delete. This ID can be obtained from the 'List Incident Workflow Triggers' endpoint or when creating a trigger. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete incident workflow trigger service **Slug:** `PAGERDUTY_DELETE_INCIDENT_WORKFLOW_TRIGGER_SERVICE` Removes a service from an incident workflow trigger in PagerDuty. This action disassociates a specific service from a trigger, preventing incidents from that service from automatically activating the workflow. Use this when you need to modify which services trigger automated incident responses. **Important Notes:** - The trigger and service must both exist and be currently associated - Returns 204 No Content on success with an empty response body - Returns 404 Not Found if the trigger or service association doesn't exist - This operation is immediate and affects future incident workflow executions - Cannot be undone - you'll need to re-add the service if removed by mistake **Common Use Cases:** - Updating which services participate in automated incident workflows - Removing a service from incident automation during maintenance - Adjusting workflow scope when service responsibilities change **Required Permissions:** incident_workflows:write OAuth scope #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `service_id` | string | Yes | The ID of the PagerDuty service to disassociate from the incident workflow trigger. After removal, incidents from this service will no longer activate this workflow trigger. | | `trigger_id` | string | Yes | The ID of the incident workflow trigger from which the service will be removed. This trigger must already exist and have the service associated with it. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete integration from event orchestration **Slug:** `PAGERDUTY_DELETE_INTEGRATION_FROM_EVENT_ORCHESTRATION` Removes a specific integration from an event orchestration in PagerDuty. This endpoint is used to disconnect a particular tool or service from the event orchestration setup, effectively stopping it from triggering or modifying incidents within that orchestration. It's particularly useful when you need to retire an old integration or reconfigure your event management workflow. Be cautious when using this endpoint, as deleting an integration is irreversible and may impact your incident response processes if not properly planned. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | | `integration_id` | string | Yes | The ID of an Integration. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete maintenance window by id **Slug:** `PAGERDUTY_DELETE_MAINTENANCE_WINDOW_BY_ID` Deletes a specific maintenance window in PagerDuty's incident management system. This endpoint is used to permanently remove a scheduled maintenance window, effectively re-enabling any services and integrations that were temporarily disabled during the maintenance period. It should be used when a maintenance window is no longer needed or was created in error. Once deleted, the maintenance window cannot be recovered, so caution should be exercised when using this endpoint. This operation is particularly useful for cleaning up obsolete maintenance windows or adjusting scheduled maintenance plans. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the maintenance window to delete. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete oncall handoff notification rule **Slug:** `PAGERDUTY_DELETE_ONCALL_HANDOFF_NOTIFICATION_RULE` This endpoint deletes a specific on-call handoff notification rule for a given user in PagerDuty. It is used to remove custom notification settings for when on-call responsibilities are transferred between team members. This operation is permanent and cannot be undone, so it should be used with caution. The endpoint is particularly useful for maintaining clean and up-to-date notification configurations, especially when certain handoff rules are no longer needed or have become obsolete. It requires both the user's ID and the specific rule ID to ensure precise targeting of the rule to be deleted. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user whose oncall handoff notification rule will be deleted. | | `oncall_handoff_notification_rule_id` | string | Yes | The ID of the oncall handoff notification rule to delete. This rule ID can be obtained from the retrieve_oncall_handoff_notification_rules action. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete post from status page **Slug:** `PAGERDUTY_DELETE_POST_FROM_STATUS_PAGE` This endpoint deletes a specific post from a PagerDuty status page. It is used to remove outdated or irrelevant information from a status page, helping to maintain clear and accurate communication with users about service status. The operation is irreversible, so it should be used with caution. This endpoint is particularly useful for cleaning up resolved incidents or removing erroneous updates. It does not provide any ability to modify or retrieve post content; it only removes the specified post entirely from the status page. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `post_id` | string | Yes | The ID of the Status Page Post. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete post update by id **Slug:** `PAGERDUTY_DELETE_POST_UPDATE_BY_ID` This endpoint deletes a specific post update from a status page post in PagerDuty. It allows users to remove outdated or incorrect information from a status page, ensuring that only relevant and accurate updates are displayed. The endpoint should be used when an organization needs to retract or remove a previously published update on their status page. It's important to note that this action is permanent and cannot be undone, so it should be used with caution. This endpoint is particularly useful for maintaining the accuracy and relevance of status page communications during incident management or scheduled maintenance periods. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page containing the post. You can get status page IDs from the 'Fetch Status Pages' action. | | `post_id` | string | Yes | The ID of the status page post containing the update to delete. You can get post IDs from the 'Create or Update Status Page Post' action or the 'List Status Page Posts' action. | | `post_update_id` | string | Yes | The ID of the specific post update to delete. You can get post update IDs from the 'Create or Update Status Page Post Update Information' action or the 'List Status Page Post Updates' action. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete response play **Slug:** `PAGERDUTY_DELETE_RESPONSE_PLAY` Deletes a specific Response Play from the PagerDuty system. This endpoint should be used when you need to remove an outdated or unnecessary Response Play from your incident management workflow. It permanently eliminates the predefined sequence of actions associated with the specified Response Play ID. Use this endpoint with caution, as the deletion is irreversible and may impact automated incident response processes. This operation is particularly useful for maintaining an up-to-date and efficient set of response strategies in your PagerDuty account. **IMPORTANT**: Response Plays are deprecated in favor of Incident Workflows. If your PagerDuty account has Incident Workflows enabled, this endpoint will return a 301 status code with the message "Incident Workflows are enabled on this account." In such cases, you should use the Incident Workflows API instead. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the response play to delete. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete rule from ruleset by id **Slug:** `PAGERDUTY_DELETE_RULE_FROM_RULESET_BY_ID` Deletes a specific event rule from a ruleset in PagerDuty. This endpoint permanently removes an individual rule from the specified ruleset. The operation cannot be undone, so use with caution as it may affect event routing and incident management workflows. NOTE: Rulesets are deprecated as of January 2025. PagerDuty recommends migrating to Event Orchestration for new implementations. This endpoint remains available for managing existing rulesets but cannot be used to create new rulesets or rules. See PagerDuty's Event Orchestration migration guide for more information. Returns a 204 No Content status on successful deletion, or 404 if the ruleset or rule is not found. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `rule_id` | string | Yes | The id of the Event Rule to delete from the ruleset. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete ruleset by id **Slug:** `PAGERDUTY_DELETE_RULESET_BY_ID` Deletes a specific ruleset from the PagerDuty system based on the provided ID. This endpoint should be used when you need to remove an existing ruleset, which may be necessary during incident management reconfiguration or when cleaning up obsolete rulesets. The deletion is permanent and cannot be undone, so use this endpoint with caution. It's important to note that deleting a ruleset will affect the incident routing and escalation policies associated with it, potentially impacting your organization's incident response workflow. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the ruleset to delete. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete runner team association **Slug:** `PAGERDUTY_DELETE_RUNNER_TEAM_ASSOCIATION` This endpoint removes a team's association from a specific Automation Action runner in PagerDuty. It is used to revoke a team's access to execute or manage tasks on a particular runner. The operation is permanent and should be used when you no longer want a team to have access to the runner's capabilities. This action is typically performed for security reasons, organizational changes, or when refining access control within your PagerDuty environment. Note that this endpoint only removes the association; it does not delete the runner or the team themselves. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the Automation Action runner from which to remove the team association. | | `team_id` | string | Yes | The ID of the team to dissociate from the runner. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete schedule by id **Slug:** `PAGERDUTY_DELETE_SCHEDULE_BY_ID` The DeleteSchedule endpoint removes a specific schedule from the PagerDuty system. It is used to delete outdated or unnecessary on-call schedules, helping to maintain an organized and efficient incident management workflow. This operation is permanent and cannot be undone, so it should be used with caution. The endpoint is particularly useful when restructuring team rotations or when a project or team associated with the schedule is no longer active. It's important to note that deleting a schedule does not affect any historical data or past incidents associated with it, but it will prevent the schedule from being used in future incident assignments. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete schedule override by id **Slug:** `PAGERDUTY_DELETE_SCHEDULE_OVERRIDE_BY_ID` This endpoint deletes a specific override from a PagerDuty schedule. It allows users to remove temporary changes made to the regular schedule, reverting it back to its original state. This operation is useful for canceling previously set overrides that are no longer needed, such as temporary shift changes or one-time schedule adjustments. The deletion is permanent and cannot be undone, so it should be used with caution. This endpoint is particularly helpful for maintaining schedule integrity and ensuring that only current and relevant overrides remain active. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `override_id` | string | Yes | The override ID on the schedule. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete service by id **Slug:** `PAGERDUTY_DELETE_SERVICE_BY_ID` Deletes a specific service from the PagerDuty account. This endpoint should be used when you need to permanently remove a service that is no longer required or active. It's important to note that this operation is irreversible and will delete all associated incidents, alerts, and integrations for the specified service. Use this endpoint with caution, as it can impact your incident management workflow. Before deletion, ensure that the service is no longer needed and that all relevant data has been backed up if necessary. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the service to delete. This is the unique PagerDuty service identifier (e.g., 'PS9CYO6'). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete service rule by id **Slug:** `PAGERDUTY_DELETE_SERVICE_RULE_BY_ID` Deletes a specific rule from a PagerDuty service. This endpoint is used to permanently remove a rule that defines conditions for incident creation or automation within a particular service. It should be used when you need to eliminate an outdated, incorrect, or no longer needed rule from your service configuration. The operation cannot be undone, so use it with caution. This endpoint does not return the deleted rule's details; it only confirms the successful deletion. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `rule_id` | string | Yes | The id of the Event Rule to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete status page postmortem **Slug:** `PAGERDUTY_DELETE_STATUS_PAGE_POSTMORTEM` This endpoint allows you to delete a postmortem associated with a specific post on a PagerDuty status page. It is used to remove the detailed analysis and lessons learned from an incident after it has been resolved and documented. This action is permanent and should be used with caution, as it will remove valuable information about past incidents. The endpoint is particularly useful for maintaining the relevance of status page content, removing outdated postmortems, or correcting information that should not have been published. It's important to note that this operation cannot be undone, so it's recommended to have a backup of the postmortem content before deletion if retention of this information is necessary for internal records. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page containing the post with the postmortem to delete. You can get status page IDs from the 'Fetch Status Pages' action. | | `post_id` | string | Yes | The ID of the status page post containing the postmortem to delete. You can get post IDs from the 'Create or Update Status Page Post' action. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete status update notification rule **Slug:** `PAGERDUTY_DELETE_STATUS_UPDATE_NOTIFICATION_RULE` Deletes a specific status update notification rule associated with a user in the PagerDuty system. This endpoint allows administrators or users with appropriate permissions to remove custom notification rules for status updates, helping to manage and streamline the user's notification preferences. It should be used when a particular status update notification rule is no longer needed or requires removal from the user's settings. The operation is irreversible, so caution should be exercised when invoking this endpoint. It's important to note that this endpoint only removes the specified rule and does not affect other notification rules or user settings. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `status_update_notification_rule_id` | string | Yes | The status update notification rule ID on the user. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete subscription from status page **Slug:** `PAGERDUTY_DELETE_SUBSCRIPTION_FROM_STATUS_PAGE` Deletes a specific subscription associated with a PagerDuty status page. This endpoint is used to remove a subscription, effectively stopping notifications or updates related to the status page for the subscribed entity. It should be used when a user or system no longer needs to receive alerts or information about a particular status page. This operation is permanent and cannot be undone, so it should be used with caution. The endpoint requires both the status page ID and the specific subscription ID to ensure precise removal of the intended subscription. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page. | | `subscription_id` | string | Yes | The ID of the Status Page subscription. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete tag by id **Slug:** `PAGERDUTY_DELETE_TAG_BY_ID` Deletes a specific tag from the PagerDuty system based on its unique identifier. This endpoint should be used when you need to remove a tag that is no longer relevant or necessary for categorizing incidents, services, or other resources in PagerDuty. It's important to note that deleting a tag will remove it from all associated resources, which could impact filtering and organization within the PagerDuty platform. This operation is irreversible, so it should be used with caution. The endpoint does not return the deleted tag's information, so if you need to reference the tag details, you should retrieve them before deletion. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the tag to delete (e.g., 'P3BCS27'). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete team by id **Slug:** `PAGERDUTY_DELETE_TEAM_BY_ID` Deletes a team from PagerDuty by its ID. This is a permanent, irreversible operation. Required: id (team ID to delete, e.g., 'PXXXXXX') Optional: reassignment_team (team ID to reassign unresolved incidents to) Important considerations: - Users in the team are NOT deleted, only the team structure is removed - Unresolved incidents can be reassigned to another team or made account-level - Associated schedules and escalation policies should be handled separately - This action cannot be undone Use cases: - Removing obsolete or unused teams - Consolidating team structures - Cleaning up after organizational changes Returns: HTTP 204 No Content on success (empty data dictionary) #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the team to delete (e.g., 'PXXXXXX'). | | `reassignment_team` | string | No | Team ID to reassign unresolved incidents to (e.g., 'PXXXXXX'). If an unresolved incident exists on both the reassignment team and the team being deleted, a duplicate will not be made. If not supplied, unresolved incidents will be made account-level. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete team escalation policy **Slug:** `PAGERDUTY_DELETE_TEAM_ESCALATION_POLICY` This endpoint removes an escalation policy association from a specific team in PagerDuty. It is used to update team configurations by disassociating an escalation policy that is no longer needed or relevant for the team's incident management process. The operation is irreversible and should be used with caution, as it may affect the team's incident response workflow. This endpoint is particularly useful when reorganizing team responsibilities or during cleanup of outdated escalation policies. It does not delete the escalation policy itself, but only removes its association with the specified team. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the team from which to remove the escalation policy association. | | `escalation_policy_id` | string | Yes | The ID of the escalation policy to disassociate from the team. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete team from automation action **Slug:** `PAGERDUTY_DELETE_TEAM_FROM_AUTOMATION_ACTION` This endpoint removes a specific team's access to an Automation Action in PagerDuty. It's used to revoke permissions when a team no longer needs to use or should not have access to a particular Automation Action. This operation is permanent and cannot be undone through this endpoint. It should be used carefully, as it will immediately prevent the specified team from executing the Automation Action. This endpoint is particularly useful for managing access control and ensuring that only authorized teams can perform certain automated tasks. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `team_id` | string | Yes | The team ID | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete template by id **Slug:** `PAGERDUTY_DELETE_TEMPLATE_BY_ID` Deletes a specific template from the PagerDuty account. This endpoint is used to permanently remove a template configuration, which can be useful for cleaning up outdated or unnecessary incident response plans. Once deleted, the template cannot be recovered, so use this operation with caution. It should be used when you no longer need a particular template for incident management or when you want to replace an old template with a new one. This operation does not affect any ongoing incidents that may have been created using the template. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the template to delete. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete user by id **Slug:** `PAGERDUTY_DELETE_USER_BY_ID` Deletes a specific user from the PagerDuty system using their unique identifier. This endpoint should be used when you need to permanently remove a user's account, such as when an employee leaves the organization or no longer requires access to the incident management system. It's important to note that deleting a user is irreversible and will remove all associated data, including their contact information, notification rules, and incident history. Before deletion, ensure that any ongoing incidents or schedules involving this user are reassigned to prevent disruptions in incident management workflows. This operation cannot be undone, so it should be used with caution and only when absolutely necessary. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete user contact method **Slug:** `PAGERDUTY_DELETE_USER_CONTACT_METHOD` Deletes a specific contact method associated with a user in PagerDuty. This endpoint should be used when you need to remove an outdated or unnecessary contact method from a user's profile. It permanently removes the specified contact method, so use with caution. This operation cannot be undone. Ensure that the user has at least one remaining contact method after deletion to maintain their ability to receive notifications. This endpoint is particularly useful for maintaining up-to-date user profiles and streamlining communication channels. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user whose contact method will be deleted. | | `contact_method_id` | string | Yes | The ID of the contact method to delete (e.g., email, phone, SMS). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete user from team by id **Slug:** `PAGERDUTY_DELETE_USER_FROM_TEAM_BY_ID` This endpoint removes a specific user from a designated team within the PagerDuty incident management platform. It is used to update team compositions by disassociating a user from a particular team, which affects the user's involvement in that team's incident responses and escalation policies. This operation is particularly useful when restructuring teams, offboarding employees, or adjusting user roles and responsibilities. The endpoint requires both the team's unique identifier and the user's unique identifier to ensure precise user-team disassociation. It's important to note that this action does not delete the user from the PagerDuty account; it only removes their association with the specified team. Use this endpoint cautiously, as it immediately affects the user's ability to receive and respond to incidents related to the team. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the team to remove the user from. | | `user_id` | string | Yes | The ID of the user to remove from the team. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete user notification rule **Slug:** `PAGERDUTY_DELETE_USER_NOTIFICATION_RULE` Deletes a specific notification rule for a user in PagerDuty. This endpoint allows administrators or users with appropriate permissions to remove custom notification rules, modifying how and when a user receives alerts about incidents. It should be used when updating a user's notification preferences or when a specific notification rule is no longer needed. The deletion is permanent and cannot be undone, so caution should be exercised when using this endpoint. It's important to note that this action does not affect the user's default notification rules or their overall ability to receive notifications; it only removes the specified custom rule. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `notification_rule_id` | string | Yes | The notification rule ID on the user. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete all user sessions **Slug:** `PAGERDUTY_DELETE_USER_SESSION_BY_ID` Deletes all active sessions for a specified user in the PagerDuty system. This endpoint is used to forcibly log out a user from all devices and applications where they might be currently authenticated. It's particularly useful for security purposes, such as when a user's credentials may have been compromised, or when offboarding an employee. The operation is irreversible and will require the user to re-authenticate on all devices. Use with caution as it may disrupt the user's ongoing work if not coordinated properly. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user whose sessions will be deleted. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete user session by type **Slug:** `PAGERDUTY_DELETE_USER_SESSION_BY_TYPE` This endpoint deletes a specific user session in PagerDuty. It is used to forcibly terminate an active session for a given user, effectively logging them out from a particular device or application. This operation is crucial for maintaining security, especially when you need to revoke access immediately, such as when a device is lost or stolen, or when suspicious activity is detected. The endpoint requires the user ID, session type, and specific session ID to accurately target and remove the desired session. It should be used cautiously as it will immediately terminate the user's access without warning. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The PagerDuty user ID whose session will be deleted. | | `type` | string | Yes | The session type. Valid values: "web" for web browser sessions, "mobile" for mobile app sessions. | | `session_id` | string | Yes | The unique identifier of the specific session to delete. Can be obtained from the get_user_sessions_by_id action. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete webhook subscription by id **Slug:** `PAGERDUTY_DELETE_WEBHOOK_SUBSCRIPTION_BY_ID` Deletes a specific webhook subscription from your PagerDuty account. This endpoint should be used when you want to stop receiving notifications for a particular webhook subscription, such as when the integration is no longer needed or when updating your notification preferences. Once deleted, the webhook subscription will immediately cease to function, and you will no longer receive notifications for the events it was configured to monitor. This action is irreversible, so use it with caution. If you need to temporarily disable notifications, consider using other management options instead of deletion. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the webhook subscription to delete. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Delete workflow integration connection **Slug:** `PAGERDUTY_DELETE_WORKFLOW_INTEGRATION_CONNECTION` Deletes a specific workflow integration connection from PagerDuty. Workflow integration connections enable PagerDuty workflows to interact with external services like AWS, Azure, Slack, and other platforms. This endpoint permanently removes a connection, which means any workflows using this connection will no longer be able to execute actions through it. This action is irreversible and cannot be undone. Before deleting a connection, ensure that no active workflows depend on it to avoid disruptions in your automation processes. Scoped OAuth requires: `workflow_integrations:connections.write` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the workflow integration connection to delete | | `integration_id` | string | Yes | The ID of the Workflow Integration | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Disassociate service dependencies **Slug:** `PAGERDUTY_DISASSOCIATE_SERVICE_DEPENDENCIES` Disassociates (removes) service dependencies in PagerDuty by deleting specified relationships between supporting and dependent services. This endpoint allows for efficient removal of multiple service dependencies in a single API call. Use this action when you need to: - Remove obsolete or incorrect service dependency relationships - Restructure service hierarchies by breaking existing dependencies - Clean up service dependency mappings during refactoring - Update the service topology by removing outdated connections Important: This operation is irreversible and will immediately affect the dependency structure. The response returns the removed relationships with their IDs. Service types are automatically normalized (e.g., 'service_reference' becomes 'technical_service_reference' in the response). #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `relationships` | array | No | List of service dependency relationships to be removed. Each relationship specifies the supporting service and dependent service whose dependency should be deleted. Multiple relationships can be removed in a single request. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Edit webhook subscription by id **Slug:** `PAGERDUTY_EDIT_WEBHOOK_SUBSCRIPTION_BY_ID` Edit an existing webhook subscription in PagerDuty to modify its configuration. This action allows you to: - Update the list of incident event types the webhook subscribes to - Change the subscription description - Enable or disable the webhook (active status) - Modify filter criteria (service/team/account scope) - though filter type changes may be restricted Use cases: - Adjust which incident events trigger webhook notifications as your needs evolve - Temporarily disable a webhook without deleting it - Update descriptions to reflect changes in webhook purpose - Fine-tune event filtering for specific services or teams Important notes: - All update parameters are optional - only include fields you want to change - The webhook's delivery method (URL, headers) cannot be changed via this endpoint - Changing filter_type after creation may not be supported by the API - The response includes the complete updated webhook configuration - The secret for payload verification is not returned in update responses (null) #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the webhook subscription to edit (required) | | `webhook__subscription__active` | boolean | No | Optional: Set to true to enable webhook delivery, false to disable. When disabled, the subscription configuration is preserved but no webhooks are sent. | | `webhook__subscription__events` | array | No | Optional: List of incident event types to receive. Valid values include: incident.triggered, incident.acknowledged, incident.resolved, incident.escalated, incident.annotated, incident.delegated, incident.priority_updated, incident.reassigned, incident.reopened, incident.unacknowledged, incident.responder.added, incident.responder.replied, incident.status_update_published | | `webhook__subscription__filter__id` | string | No | Optional: The ID of the service or team to filter events. Required when filter_type is service_reference or team_reference. Not needed for account_reference. Note: Changing filter type after creation may not be supported by the API. | | `webhook__subscription__description` | string | No | Optional: A short description of the webhook subscription to help identify its purpose | | `webhook__subscription__filter__type` | string ("account_reference" | "service_reference" | "team_reference") | No | Optional: The scope of events to receive. Options: 'account_reference' (all account events), 'service_reference' (specific service events, requires filter_id), 'team_reference' (specific team events, requires filter_id). Note: Changing filter type after creation may not be supported by the API. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Enable extension by id **Slug:** `PAGERDUTY_ENABLE_EXTENSION_BY_ID` Enables a temporarily disabled extension in PagerDuty. Extensions (such as webhooks and custom integrations) can be automatically disabled by PagerDuty when there are repeated delivery failures, timeouts, or other issues. This endpoint reactivates such extensions after the underlying issues have been resolved. Common reasons extensions are disabled: - Webhook endpoint returns non-2xx status codes repeatedly - Webhook endpoint times out or responds too slowly - 3xx redirects from the webhook URL - Authentication failures at the webhook endpoint The endpoint is idempotent and can be called on already-enabled extensions without error. After enabling, verify that the underlying issue (e.g., webhook endpoint availability, correct URL, proper authentication) has been fixed to prevent the extension from being disabled again. The extension is identified by its unique ID. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the extension to enable. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Enable webhook subscription by id **Slug:** `PAGERDUTY_ENABLE_WEBHOOK_SUBSCRIPTION_BY_ID` Activates a specific webhook subscription in PagerDuty, enabling the system to send notifications for the events configured in that subscription. This endpoint should be used when you want to start receiving webhook notifications after creating or previously disabling a subscription. It's particularly useful for managing notification flows dynamically, such as during maintenance periods or when integrating new systems. Note that this operation only affects the specified subscription and does not modify its configuration or event filters. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Execute response play by id **Slug:** `PAGERDUTY_EXECUTE_RESPONSE_PLAY_BY_ID` Executes a predefined Response Play for a specific incident in PagerDuty. This endpoint allows you to trigger a sequence of automated actions designed to manage and respond to the given incident. It's useful for standardizing and streamlining your incident response process, ensuring consistent handling of similar incidents. The endpoint requires you to specify the incident for which the Response Play should be run, using the incident's unique identifier. Note that the Response Play itself is identified by the ID in the URL path, not in the request body. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `From` | string | Yes | REQUIRED: Email address of a valid user associated with the PagerDuty account. This user must have permissions to execute response plays. The email is used to attribute the action and ensure proper authorization. You can use the GET /users/me endpoint to get the current user's email. Example: "user@example.com" | | `incident__id` | string | Yes | The unique identifier of the incident on which to run the Response Play. This is the incident that will have the Response Play's actions applied to it. You can obtain incident IDs from the GET /incidents endpoint or from incident creation responses. Example: "Q3X7Z8D90ABCDE". Pattern: Typically starts with a letter followed by alphanumeric characters. | | `incident__type` | string | No | The object type for the incident reference. Must be "incident_reference" to properly identify the incident object type in the API request. | | `response_play_id` | string | Yes | The unique identifier of the Response Play to execute. Response Plays are predefined sets of actions that can be applied to incidents. You can obtain response play IDs using the GET /response_plays endpoint with filter_for_manual_run=true. Example: "PLAY123". Note: Response Plays have been deprecated by PagerDuty in favor of Incident Workflows. If your account has migrated to Incident Workflows, this endpoint may return a 301 redirect. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch cache variable for event orchestration **Slug:** `PAGERDUTY_FETCH_CACHE_VARIABLE_FOR_EVENT_ORCHESTRATION` Retrieves detailed information about a specific cache variable in a PagerDuty event orchestration. Cache variables store dynamic data from events (recent values, trigger counts, or external data) to enable complex routing and automation workflows. Returns: Variable ID, name, configuration (type and settings), conditions (PCL expressions), disabled status, and metadata (timestamps, user references). Use cases: Inspect configuration before updates, debug orchestration logic, audit settings, verify automation rules. Prerequisites: Event Intelligence/Digital Operations plan or AIOps add-on, event_orchestrations:read scope, Team Manager+ permissions. Note: Read-only. Use fetch_event_orchestrations to get orchestration IDs, get_event_orchestration_cache_variables to list all variables. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier (UUID format) of the Event Orchestration. Example: 'P1ABC23' or 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' | | `cache_variable_id` | string | Yes | The unique identifier (UUID format) of the Cache Variable to fetch. Example: 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch custom incident field by id **Slug:** `PAGERDUTY_FETCH_CUSTOM_INCIDENT_FIELD_BY_ID` Retrieves detailed information about a specific custom field associated with incidents in PagerDuty. This endpoint allows users to fetch the configuration and attributes of a custom field by providing its unique identifier. It's useful for verifying custom field settings, understanding the structure of additional data points on incidents, or preparing to update a custom field. The endpoint should be used when detailed information about a particular custom field is needed, such as its name, data type, or any predefined options. Note that this endpoint only provides information about the custom field itself, not the values assigned to incidents. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `include` | string ("field_options") | No | Additional details to include in the response. Use 'field_options' to include the available options for this custom field. | | `field_id` | string | Yes | The unique identifier of the custom incident field to retrieve. This is the ID returned when creating or listing custom fields. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch escalation polices list **Slug:** `PAGERDUTY_FETCH_ESCALATION_POLICES_LIST` Retrieves a list of escalation policies configured in the PagerDuty account. This endpoint allows users to access detailed information about how incidents are escalated within their organization, including the sequence of notifications and assignments for different teams or individuals. It's particularly useful for reviewing and auditing the incident response process, ensuring that critical alerts are properly routed and escalated. The endpoint provides a comprehensive view of all escalation policies, which is essential for maintaining an effective incident management strategy. However, it does not modify any existing policies or create new ones; it's purely for retrieval and review purposes. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `query` | string | No | Filters the result, showing only the records whose name matches the query. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | | `include` | array | No | Array of additional data to include in the response. Can include 'services', 'teams', and/or 'targets' to get detailed information about associated entities. | | `sort_by` | string ("name" | "name:asc" | "name:desc") | No | Used to specify the field you wish to sort the results on. | | `team__ids` | array | No | An array of team IDs. Only results related to these teams will be returned. Account must have the `teams` ability to use this parameter. | | `user__ids` | array | No | Filters the results, showing only escalation policies on which any of the users is a target. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch event orchestrations **Slug:** `PAGERDUTY_FETCH_EVENT_ORCHESTRATIONS` Retrieves a list of event orchestrations configured in the PagerDuty account. Event orchestrations are used to manage and automate the routing and handling of events and incidents. This endpoint allows you to fetch details about existing orchestrations, which can be useful for auditing, reporting, or managing your incident response workflows. The response typically includes information such as orchestration names, associated routing keys, and configured rules. Use this endpoint when you need to review or list the current event orchestrations in your PagerDuty setup. Note that this endpoint does not provide real-time event data or incident details, only the configuration of the orchestrations themselves. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | Maximum number of event orchestrations to return per page. If not specified, defaults to 25. Use with offset for pagination. | | `offset` | integer | No | Number of event orchestrations to skip before returning results. Used for pagination. Defaults to 0 if not specified. | | `sort_by` | string ("name:asc" | "name:desc" | "routes:asc" | "routes:desc" | "created_at:asc" | "created_at:desc") | No | Field and order to sort results by. Options: 'name:asc', 'name:desc', 'routes:asc', 'routes:desc', 'created_at:asc', 'created_at:desc'. Defaults to 'name:asc' (alphabetical by name). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch incident analytics by id **Slug:** `PAGERDUTY_FETCH_INCIDENT_ANALYTICS_BY_ID` Retrieves raw analytics data for a specific incident in PagerDuty. This endpoint provides unprocessed incident information, allowing for detailed analysis and custom reporting. It should be used when in-depth, granular data about a particular incident is needed, such as for investigating complex issues or generating custom analytics. The endpoint returns comprehensive incident details, which may include timestamps, status changes, assignee information, and other relevant metrics. However, it does not provide pre-analyzed or aggregated data; users will need to process the raw data themselves for specific insights. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch incident list **Slug:** `PAGERDUTY_FETCH_INCIDENT_LIST` Retrieves a list of incidents from PagerDuty based on specified criteria. This endpoint allows users to fetch multiple incidents, making it useful for incident management, reporting, and analysis. It supports filtering by status and date range, as well as pagination for handling large result sets. The endpoint is particularly valuable for obtaining an overview of recent or ongoing incidents, tracking incident trends, or integrating PagerDuty incident data into external systems or dashboards. Note that while this endpoint provides a summary of incidents, it may not include full details for each incident; separate API calls might be necessary to fetch comprehensive information for individual incidents. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | Number of incidents to return per page. Must be between 1 and 100. Default is 25 if not specified. Use with offset for pagination. | | `since` | string | No | Start of date range filter (ISO 8601 format). Only incidents created after this time are returned. Example: '2024-01-01T00:00:00Z'. Maximum range is 6 months. Defaults to 1 month ago if not specified. Ignored when date_range='all'. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `until` | string | No | End of date range filter (ISO 8601 format). Only incidents created before this time are returned. Example: '2024-12-31T23:59:59Z'. Must be within 6 months of 'since' parameter. Defaults to now if not specified. Ignored when date_range='all'. | | `offset` | integer | No | Pagination offset to start results from. Use with limit for pagination. For example, offset=25 with limit=25 returns results 26-50. Default is 0. | | `include` | array | No | Array of additional details to include in the response. Available options: 'acknowledgers', 'agents', 'assignees', 'conference_bridge', 'escalation_policies', 'first_trigger_log_entries', 'priorities', 'services', 'teams', 'users'. Including these expands the response with additional related object details. | | `sort_by` | array | No | Sort incidents by specified fields and direction. Format: 'field:direction'. Available fields: 'incident_number', 'created_at', 'resolved_at', 'urgency'. Direction: 'asc' (default) or 'desc'. Examples: ['created_at:desc'], ['urgency:desc', 'created_at:asc']. Maximum two fields. Sorting by urgency requires the 'urgencies' account ability. | | `statuses` | array | No | Filter incidents by status. Accepts multiple values: 'triggered', 'acknowledged', 'resolved'. Returns only incidents matching the specified statuses. If not specified, returns incidents of all statuses. | | `team__ids` | array | No | An array of team IDs. Only results related to these teams will be returned. Account must have the `teams` ability to use this parameter. | | `time_zone` | string | No | Time zone for rendering dates/times in response. Uses IANA time zone format (e.g., 'America/New_York', 'UTC', 'Europe/London'). Defaults to account's configured time zone if not specified. | | `urgencies` | array | No | Array of urgencies to filter incidents. Accepts multiple values: 'high', 'low'. Defaults to all urgencies if not specified. Account must have the `urgencies` ability to use this filter. | | `user__ids` | array | No | Returns only the incidents currently assigned to the passed user(s). This expects one or more user IDs. Note: When using the assigned_to_user filter, you will only receive incidents with statuses of triggered or acknowledged. This is because resolved incidents are not assigned to any user. | | `date_range` | string ("all") | No | When set to all, the since and until parameters and defaults are ignored. | | `incident_key` | string | No | Incident de-duplication key. Incidents with child alerts do not have an incident key; querying by incident key will return incidents whose alerts have alert_key matching the given incident key. | | `service__ids` | array | No | Returns only the incidents associated with the passed service(s). This expects one or more service IDs. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch outlier incident by id **Slug:** `PAGERDUTY_FETCH_OUTLIER_INCIDENT_BY_ID` Retrieves detailed information about an outlier incident associated with a specific incident in PagerDuty. This endpoint is used to gather insights on incidents that deviate significantly from normal patterns, helping teams identify and analyze unusual or potentially critical issues. It should be used when investigating anomalies in incident patterns or when conducting post-incident reviews. The endpoint provides specific data about the outlier incident, which can be crucial for understanding unique characteristics or severity of the issue compared to typical incidents. **Note**: This feature requires the PagerDuty AIOps add-on. Services must have AIOps enabled to access outlier incident data. Without this add-on, requests will return a 403 Forbidden error. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The incident ID to fetch outlier information for. | | `since` | string | No | The start of the date range over which you want to search. | | `additional__details` | array | No | Additional details to include in the response. Can include 'incident' to get full incident details for related incidents. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch post update status **Slug:** `PAGERDUTY_FETCH_POST_UPDATE_STATUS` Retrieves detailed information about a specific post update on a PagerDuty status page. This endpoint allows you to fetch the content and metadata of a particular update made to a post, providing insight into the chronological changes and communications related to an incident or maintenance event. Use this when you need to review or display the exact content of a specific update, such as for auditing purposes or to provide detailed information to stakeholders. The endpoint requires the unique identifiers for the status page, the post, and the specific update, ensuring precise retrieval of the desired information. It's particularly useful for tracking the evolution of an incident's communication or for analyzing the effectiveness of status updates over time. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the Status Page. You can get status page IDs by using the 'List Status Pages' action (PAGERDUTY_FETCH_STATUS_PAGES). | | `post_id` | string | Yes | The ID of the Status Page Post. You can get post IDs from the 'List Status Page Posts' action or from the response of creating a post with PAGERDUTY_CREATE_OR_UPDATE_STATUS_PAGE_POST. | | `post_update_id` | string | Yes | The ID of the specific Post Update within the post. You can get update IDs from the post's updates array when retrieving a post, or from the response of creating an update with PAGERDUTY_UPDATE_STATUS_PAGE_POST_INFO. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch priorities list **Slug:** `PAGERDUTY_FETCH_PRIORITIES_LIST` Retrieves a list of existing priorities in the PagerDuty system, ordered from most severe to least severe. This endpoint should be used when you need to obtain information about the current priority levels configured in your PagerDuty account. It's particularly useful for integrations that need to reference or display priority information, or for administrators who want to review the existing priority structure. The endpoint provides a read-only view of priorities and does not allow for creation, modification, or deletion of priority levels. Keep in mind that this API call is subject to rate limiting, so it should not be called excessively in short periods. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. Note: The priorities endpoint may return all priorities regardless of this parameter as the list is typically small. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. Note: The priorities endpoint may not support offset as the list is typically small. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch related change events for incident **Slug:** `PAGERDUTY_FETCH_RELATED_CHANGE_EVENTS_FOR_INCIDENT` Retrieves change events correlated with a specific incident, along with the reasons for correlation. Change events represent service changes such as deploys, build completions, and configuration updates that may be related to the incident. Change correlation is based on three factors: - Time: Recent changes within 24 hours of the incident - Related service: Changes to services involved in the incident - Intelligence: Machine learning-based relevance scoring Use this action to: - Understand what recent changes might have caused an incident - Investigate incident root causes during triage - Compile comprehensive incident reports with change context - Audit system changes related to specific incidents IMPORTANT: This endpoint requires the PagerDuty AIOps add-on (Enterprise plan feature). Accounts without this add-on will receive a 403 Forbidden error. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident to retrieve related change events for. Example: 'Q1LM34T0WT52EL' | | `limit` | integer | No | Maximum number of change events to return per page. If not specified, returns all available change events (typically up to 100). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch related incidents by id **Slug:** `PAGERDUTY_FETCH_RELATED_INCIDENTS_BY_ID` Retrieves a list of incidents that are potentially related to a specified incident in PagerDuty. This endpoint utilizes machine learning algorithms to identify and return up to 20 recent incidents on other services that may be connected or similar to the given incident. It's particularly useful for incident management teams to gain a broader context of ongoing issues, identify patterns, and potentially streamline resolution processes. The endpoint should be used when investigating an incident to discover any correlated problems or when trying to understand the wider impact of a particular issue across the system. It does not modify any incident data and is intended for informational purposes only. **Note**: This feature requires the PagerDuty AIOps add-on. Services must have AIOps enabled to access related incident data. Without this add-on, requests will return a 404 Not Found error. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident to fetch related incidents for. | | `additional__details` | array | No | Array of additional attributes to any of the returned incidents for related incidents. Can include 'incident' to get full incident details for related incidents. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch runner teams integration **Slug:** `PAGERDUTY_FETCH_RUNNER_TEAMS_INTEGRATION` Retrieves a list of teams associated with a specific Automation Action Runner in PagerDuty. This endpoint allows users to identify which teams have access to or are responsible for a particular runner, facilitating better management and organization of automation resources. It's particularly useful for administrators who need to audit runner permissions or when planning to modify team access to automation capabilities. The endpoint returns team information related to the specified runner only and does not provide details about the runner itself or its automation actions. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the Automation Action Runner for which to retrieve team associations. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch status pages **Slug:** `PAGERDUTY_FETCH_STATUS_PAGES` Retrieves a list of all status pages configured in the PagerDuty account. Status pages provide real-time information about the operational status of services, ongoing incidents, and planned maintenance. This endpoint should be used when you need to obtain an overview of all available status pages, which can be useful for monitoring, reporting, or integrating status information into other systems. The response will include details such as the status page ID, name, and current state. Note that this endpoint does not provide the actual content of each status page, but rather metadata about the pages themselves. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `status_page_type` | string ("public" | "private") | No | Filter status pages by type. 'public' returns status pages accessible to anyone with the URL, while 'private' returns status pages restricted to authenticated users only. If not specified, returns all status pages regardless of type. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch user contact method **Slug:** `PAGERDUTY_FETCH_USER_CONTACT_METHOD` Retrieves detailed information about a specific contact method for a particular user in PagerDuty. This endpoint allows you to fetch the configuration and settings of a single contact method, such as an email address, phone number, or push notification settings, associated with a user's account. It's useful for verifying or auditing user contact information, or when you need to display or update a specific contact method. The endpoint requires both the user ID and the contact method ID to pinpoint the exact resource. It does not modify any data and is safe for frequent calls, but should be used judiciously in high-volume scenarios to avoid hitting rate limits. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `contact_method_id` | string | Yes | The contact method ID on the user. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Fetch vendor list **Slug:** `PAGERDUTY_FETCH_VENDOR_LIST` Retrieves a list of vendors or third-party integrations available in the PagerDuty platform. This endpoint allows users to access information about various services and tools that can be integrated with PagerDuty for enhanced incident management and alerting capabilities. Use this endpoint when you need to explore or review the available integrations, such as monitoring tools, ticketing systems, or communication platforms. The response likely includes details such as vendor names, integration types, and possibly configuration options. Note that this endpoint does not provide real-time status of integrations or perform any actions on the integrations themselves. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Filter and aggregate incident metrics **Slug:** `PAGERDUTY_FILTER_AND_AGGREGATE_INCIDENT_METRICS` Analyzes and aggregates incident metrics across teams in PagerDuty, allowing for detailed filtering and customization of results. This endpoint is used to gain insights into incident patterns, team performance, and overall operational efficiency. It provides flexible options for data selection, time range specification, and result presentation, making it valuable for generating reports, identifying trends, and optimizing incident management processes. The endpoint is particularly useful for operational reviews, team performance assessments, and strategic planning in incident response. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `order` | string ("asc" | "desc") | No | The order in which the results were sorted; asc for ascending, desc for descending. | | `order_by` | string | No | The column that was used for ordering the results. | | `time_zone` | string | No | The time zone to use for the results and grouping. Must be in tzdata format. See list of accepted values [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). | | `aggregate_unit` | string ("day" | "week" | "month") | No | The time unit to aggregate metrics by. If no value is provided, the metrics will be aggregated for the entire period. | | `filters__major` | boolean | No | A boolean flag including whether results should contain *only* [major incidents](https://support.pagerduty.com/docs/operational-reviews#major-incidents), or exclude major incidents. If no value is provided all incidents will be included. | | `filters__urgency` | string ("high" | "low") | No | Any incidents whose urgency does not match the provided string will be omitted from the results. | | `filters__team__ids` | array | No | An array of team IDs. Only incidents related to these teams will be included in the results. If omitted, all teams the requestor has access to will be included in the results. | | `filters__service__ids` | array | No | An array of service IDs. Only incidents related to these services will be included in the results. If omitted, all services the requestor has access to will be included in the results. | | `filters__priority__ids` | array | No | An array of priority IDs. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__priority__names` | array | No | An array of user-defined priority names. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__created__at__end` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at greater than or equal to this value will be omitted from the results. The maximum supported time range in conjunction with created_at_start is one year. | | `filters__pd__advance__used` | boolean | No | If true, only incidents where PD Advance was used will be included in the results, and vice versa. If omitted, all incidents will be included. | | `filters__created__at__start` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at less than this value will be omitted from the results. The maximum supported time range in conjunction with created_at_end is one year. | | `filters__min__acknowledgements` | integer | No | An integer that sets the requirement for the minimum number of acknowledgements to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 acknowledgement. If no value is provided, all incidents will be included. | | `filters__escalation__policy__ids` | array | No | An array of escalation policy IDs. Only incidents related to these escalation policies will be included in the results. If omitted, all escalation policies the requestor has access to will be included in the results. | | `filters__min__manual__escalations` | integer | No | An integer that sets the requirement for the minimum number of manual escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 manual escalation. If no value is provided, all incidents will be included. | | `filters__min__timeout__escalations` | integer | No | An integer that sets the requirement for the minimum number of timeout escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 timeout escalation. If no value is provided, all incidents will be included. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get addons list **Slug:** `PAGERDUTY_GET_ADDONS_LIST` Retrieves a list of all addons associated with the PagerDuty account. This endpoint allows users to view the additional features or integrations that have been added to enhance the platform's capabilities. It provides an overview of the current addons, which can include third-party services or custom extensions that extend the functionality of the core PagerDuty system. This endpoint is useful for auditing the account's current addons, planning for potential new integrations, or managing existing ones. Note that this endpoint only returns basic information about the addons and may not include detailed configuration settings for each addon. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `filter` | string ("full_page_addon" | "incident_show_addon") | No | Filters the results, showing only Add-ons of the given type | | `offset` | integer | No | Offset to start pagination search results. | | `include` | string ("services") | No | Array of additional Models to include in response. | | `service__ids` | array | No | Filters the results, showing only Add-ons for the given services | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get a field option on a custom field **Slug:** `PAGERDUTY_GET_A_FIELD_OPTION_ON_A_CUSTOM_FIELD` Retrieves a specific field option from a custom field on an incident type. Field options represent the selectable values for multi-value or dropdown custom fields in PagerDuty. This action returns details about a single field option including its value, data type, and other metadata. **Prerequisites:** 1. A valid incident type ID or name (use PAGERDUTY_LIST_INCIDENT_TYPES) 2. A valid custom field ID for that incident type (use PAGERDUTY_LIST_INCIDENT_TYPE_CUSTOM_FIELDS) 3. A valid field option ID for that custom field (use PAGERDUTY_LIST_FIELD_OPTIONS_ON_A_CUSTOM_FIELD) **Note:** This is an Early Access endpoint requiring the `custom_fields.read` OAuth scope. The X-EARLY-ACCESS header with value 'analytics-v2' is automatically included. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field_id` | string | Yes | The ID of the custom field that contains the field option. Use LIST_INCIDENT_TYPE_CUSTOM_FIELDS to find valid field IDs for an incident type. | | `field_option_id` | string | Yes | The ID of the specific field option to retrieve. Use LIST_FIELD_OPTIONS_ON_A_CUSTOM_FIELD to find valid field option IDs. | | `type_id_or_name` | string | Yes | The ID or name of the Incident Type. Use LIST_INCIDENT_TYPES to find valid incident type IDs or names. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get aggregated pd advance usage data **Slug:** `PAGERDUTY_GET_AGGREGATED_PD_ADVANCE_USAGE_DATA` Provides aggregated metrics for the usage of PD Advance. > **Note:** Analytics data is updated [periodically](https://support.pagerduty.com/main/docs/insights#:~:text=Data%20Update%20Schedule). It takes up to 24 hours before new incidents appear in the Analytics API. Scoped OAuth requires: `analytics.read` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `time_zone` | string | No | The time zone to use for the results and grouping. Must be in tzdata format. See list of accepted values [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). | | `filters__major` | boolean | No | A boolean flag including whether results should contain *only* [major incidents](https://support.pagerduty.com/docs/operational-reviews#major-incidents), or exclude major incidents. If no value is provided all incidents will be included. | | `filters__urgency` | string ("high" | "low") | No | Any incidents whose urgency does not match the provided string will be omitted from the results. | | `filters__team_ids` | array | No | An array of team IDs. Only incidents related to these teams will be included in the results. If omitted, all teams the requestor has access to will be included in the results. | | `filters__service_ids` | array | No | An array of service IDs. Only incidents related to these services will be included in the results. If omitted, all services the requestor has access to will be included in the results. | | `filters__priority_ids` | array | No | An array of priority IDs. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__created_at_end` | string | No | Accepts an ISO8601 DateTime string. Any PD Advance usage with a created_at greater than or equal to this value will be omitted from the results. The maximum supported time range in conjunction with created_at_start is one year. | | `filters__priority_names` | array | No | An array of user-defined priority names. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__created_at_start` | string | No | Accepts an ISO8601 DateTime string. Any PD Advance usage with a created_at less than this value will be omitted from the results. The maximum supported time range in conjunction with created_at_end is one year. | | `filters__min_acknowledgements` | integer | No | An integer that sets the requirement for the minimum number of acknowledgements to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 acknowledgement. If no value is provided, all incidents will be included. | | `filters__escalation_policy_ids` | array | No | An array of escalation policy IDs. Only incidents related to these escalation policies will be included in the results. If omitted, all escalation policies the requestor has access to will be included in the results. | | `filters__min_manual_escalations` | integer | No | An integer that sets the requirement for the minimum number of manual escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 manual escalation. If no value is provided, all incidents will be included. | | `filters__incident_created_at_end` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at greater than or equal to this value will be omitted from the results. The maximum supported time range in conjunction with incident_created_at_start is one year. | | `filters__min_timeout_escalations` | integer | No | An integer that sets the requirement for the minimum number of timeout escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 timeout escalation. If no value is provided, all incidents will be included. | | `filters__incident_created_at_start` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at less than this value will be omitted from the results. The maximum supported time range in conjunction with incident_created_at_end is one year. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get alert grouping settings **Slug:** `PAGERDUTY_GET_ALERT_GROUPING_SETTINGS` Lists all alert grouping settings configured in your PagerDuty account. Alert grouping settings control how multiple related alerts are automatically combined into a single incident, reducing noise and improving incident management. This endpoint returns settings including: - Grouping types: intelligent (ML-based), content_based, time-based, or content_based_intelligent - Configuration details: time windows, grouping fields (iag_fields), and other parameters - Associated services: which services each setting applies to Use this action to: - Audit current alert grouping configurations across your account - Discover which services have specific grouping rules applied - Retrieve setting IDs for use with update or delete operations - Understand how alerts are being consolidated in your incident workflow The response can be filtered by service IDs and supports pagination for accounts with many settings. Note that this returns configured settings, not real-time grouping status of active incidents. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `after` | string | No | Pagination cursor to retrieve the next page of results. Obtained from the 'after' field in a previous response. Leave empty for the first request. | | `limit` | integer | No | The maximum number of alert grouping settings to return per page. If not specified, defaults to 25. Use this to control pagination. | | `total` | boolean | No | Set to true to include the total count of results in the response. By default, this is false for faster response times. When true, the response will include a 'total' field indicating the total number of alert grouping settings available. | | `before` | string | No | Pagination cursor to retrieve the previous page of results. Obtained from the 'before' field in a previous response. Leave empty for the first request. | | `service__ids` | array | No | Filter results to only include alert grouping settings associated with the specified service IDs. Provide an array of PagerDuty service IDs (e.g., ['PXXXXXX', 'PXXXXXX']). Leave empty to retrieve all alert grouping settings regardless of service. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get alerts by incident id **Slug:** `PAGERDUTY_GET_ALERTS_BY_INCIDENT_ID` Retrieves all alerts associated with a specific incident in PagerDuty. Alerts are the raw events that triggered or contributed to an incident. This endpoint allows users to fetch detailed information about these alerts, including their status, creation time, severity, and related service information. It is particularly useful for incident postmortems, auditing purposes, understanding alert grouping behavior, or investigating which monitoring events led to an incident. The endpoint returns a paginated list of alerts with optional filtering by status or alert_key, and supports including additional related data like services, first trigger log entries, or parent incident details. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The incident ID to retrieve alerts for. | | `limit` | integer | No | The number of results per page. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | | `include` | string ("services" | "first_trigger_log_entries" | "incidents") | No | Additional details to include in the response. Options: 'services' includes service details for each alert, 'first_trigger_log_entries' includes the first trigger log entry for each alert, 'incidents' includes the parent incident details. | | `sort_by` | string ("created_at" | "resolved_at" | "created_at:asc" | "created_at:desc" | "resolved_at:asc" | "resolved_at:desc") | No | Used to specify both the field you wish to sort the results on (created_at/resolved_at), as well as the direction (asc/desc) of the results. The sort_by field and direction should be separated by a colon. A maximum of two fields can be included, separated by a comma. Sort direction defaults to ascending. | | `statuses` | string ("triggered" | "resolved") | No | Return only alerts with the given statuses. (More status codes may be introduced in the future.) | | `alert_key` | string | No | Alert de-duplication key. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get analytics metrics incidents all **Slug:** `PAGERDUTY_GET_ANALYTICS_METRICS_INCIDENTS_ALL` Retrieves aggregated incident analytics data for all incidents in PagerDuty. Use when you need comprehensive incident metrics across teams, services, and escalation policies. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `order` | string ("asc" | "desc") | No | Order for sorting results | | `filters` | object | No | Filter parameters for incident analytics query | | `order_by` | string | No | The column that was used for ordering the results. | | `time_zone` | string | No | The time zone to use for the results and grouping. Must be in tzdata format. See list of accepted values here: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones | | `aggregate_unit` | string ("day" | "week" | "month") | No | Time unit for aggregating metrics | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get analytics metrics users all **Slug:** `PAGERDUTY_GET_ANALYTICS_METRICS_USERS_ALL` Get aggregated metrics for all users across the account. Returns user adoption and engagement metrics including mobile app downloads, escalation policy assignments, sign-up rates, and notification method configuration. Use when analyzing user adoption patterns, identifying users who need onboarding support, or generating reports on team readiness and engagement. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `filters` | object | No | Filter conditions for analytics user queries | | `time_zone` | string | No | The time zone to use for the results and grouping. Must be in tzdata format (e.g., 'America/New_York', 'Europe/London', 'Etc/UTC'). See list at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get analytics raw incidents responses **Slug:** `PAGERDUTY_GET_ANALYTICS_RAW_INCIDENTS_RESPONSES` Retrieves raw response data from a single incident in PagerDuty. Use this when you need detailed information about who was asked to respond to a specific incident and their response status. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident to retrieve responses for. | | `limit` | integer | No | Number of results to include in each batch. Limits between 1 to 1000 are accepted. | | `order` | string ("asc" | "desc") | No | Order direction for sorting results | | `order_by` | string ("requested_at") | No | Column to use for ordering results | | `time_zone` | string | No | The time zone to use for the results. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get analytics raw users **Slug:** `PAGERDUTY_GET_ANALYTICS_RAW_USERS` Get raw user analytics data from PagerDuty. Use when you need detailed user activity and configuration metrics for analysis and reporting. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The maximum number of results to return per page. The default (and maximum allowed value) is 1000. | | `order` | string ("asc" | "desc") | No | The order in which the results were sorted; asc for ascending, desc for descending. | | `order_by` | string | No | The column that was used for ordering the results. | | `time_zone` | string | No | The time zone to use for the results and grouping. Must be in tzdata format. See list of accepted values at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones | | `ending_before` | string | No | A cursor used for pagination. Ending before cursor provides the previous set of results in reverse pagination order. | | `aggregate_unit` | string ("day" | "week" | "month") | No | The time unit to aggregate metrics by. If no value is provided, the metrics will be aggregated for the entire period. | | `starting_after` | string | No | A cursor used for pagination. Starting after cursor provides the next set of results in forward pagination order. | | `filters__role__ids` | array | No | An array of role IDs. Only users with these roles will be included in results. | | `filters__team__ids` | array | No | An array of team IDs. Only users belonging to these teams will be included in results. | | `filters__user__ids` | array | No | An array of user IDs. Only these users will be included in results. | | `filters__created__at__end` | string | No | The end of the date range to search (ISO 8601 format) | | `filters__created__at__start` | string | No | The start of the date range to search (ISO 8601 format) | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get an incident type **Slug:** `PAGERDUTY_GET_AN_INCIDENT_TYPE` Get detailed information about a single incident type. Accepts either an incident type id, or an incident type name. Incident Types are a feature which will allow customers to categorize incidents, such as a security incident, a major incident, or a fraud incident. > ### Early Access > This endpoint is in Early Access and may change at any time. You must pass in the X-EARLY-ACCESS header to access it. For more information see the [API Concepts Document](../../api-reference/ZG9jOjI3NDc5Nzc-api-concepts#incident) Scoped OAuth requires: `incident_types.read` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `type_id_or_name` | string | Yes | The ID (e.g., 'P5VNOVL') or name (e.g., 'incident_default') of the Incident Type to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get an incident type custom field **Slug:** `PAGERDUTY_GET_AN_INCIDENT_TYPE_CUSTOM_FIELD` Get a custom field for an incident type. Custom Fields (CF) are a feature which will allow customers to extend Incidents with their own custom data, to provide additional context and support features such as customized filtering, search and analytics. Custom Fields can be applied to different incident types. > ### Early Access > This endpoint is in Early Access and may change at any time. You must pass in the X-EARLY-ACCESS header to access it. Scoped OAuth requires: `custom_fields.read` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `include` | string ("field_options") | No | Additional details to include in the response. Use 'field_options' to include predefined field options. | | `field_id` | string | Yes | The ID of the field. | | `type_id_or_name` | string | Yes | The ID or name of the Incident Type. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get incident workflow trigger **Slug:** `PAGERDUTY_GET_A_TRIGGER` Retrieves details of a specific incident workflow trigger by ID. Incident workflow triggers define when and how workflows are activated - either automatically based on conditions (conditional), manually by responders (manual), or for specific incident types (incident_type). The response includes the trigger type, associated workflow, services, conditions, and permissions. This is useful for understanding workflow automation configuration and debugging workflow execution. Requires the `incident_workflows.read` OAuth scope. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident workflow trigger to retrieve | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get audit records **Slug:** `PAGERDUTY_GET_AUDIT_RECORDS` Retrieves a list of audit records from the PagerDuty system. This endpoint allows users to access logs of configuration changes made to PagerDuty resources, such as account objects. The records are sorted by execution time, with the newest records appearing first. This tool is particularly useful for tracking and reviewing changes, conducting security audits, or generating reports on system modifications. It provides a comprehensive view of who made what changes and when, enhancing transparency and accountability within the organization. The endpoint supports pagination and date range filtering to manage large volumes of audit data effectively. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The maximum number of audit records to return per page. If not specified, the API will use its default page size. | | `since` | string | No | The start of the date range over which you want to search, in ISO 8601 format (e.g., '2024-01-15T00:00:00Z'). If not specified, defaults to 24 hours ago. | | `until` | string | No | The end of the date range over which you want to search, in ISO 8601 format (e.g., '2024-01-31T23:59:59Z'). If not specified, defaults to now. Must not be more than 31 days after 'since'. | | `cursor` | string | No | Optional parameter used to request the "next" set of results from an API. The value provided here is most commonly obtained from the `next_cursor` field of the previous request. When no value is provided, the request starts at the beginning of the result set. | | `actions` | array | No | Filter audit records by action types. Can specify multiple actions (e.g., ['create', 'update']). Available actions: create, update, delete. | | `actor_id` | string | No | Filter by the specific ID of the actor who performed the action. Must be used together with the 'actor_type' parameter. | | `actor_type` | string ("user_reference" | "api_key_reference" | "app_reference") | No | Filter by the type of actor who performed the action. Available values: user_reference, api_key_reference, app_reference. | | `method_type` | string ("browser" | "oauth" | "api_token" | "identity_provider" | "other") | No | Filter by the authentication method used. Available values: browser, oauth, api_token, identity_provider, other. | | `root__resource__types` | array | No | Filter audit records by root resource types. Can specify multiple types (e.g., ['users', 'teams']). Available types: users, teams, schedules, escalation_policies, services. | | `method_truncated_token` | string | No | Filter by a truncated API token or OAuth token. This is the last few characters of the token used for authentication. Must be used together with the 'method_type' parameter. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get automation action by id **Slug:** `PAGERDUTY_GET_AUTOMATION_ACTION_BY_ID` Retrieves detailed information about a specific automation action in PagerDuty's incident management platform. This endpoint allows users to fetch the configuration and attributes of a predefined automation action by its unique identifier. It's particularly useful when you need to review or audit the settings of an existing automation action, such as its triggers, conditions, or associated workflows. The endpoint should be used when detailed information about a single automation action is required, rather than for listing multiple actions. Note that this endpoint only provides read access to the automation action details and cannot be used to modify the action. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the automation action to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get automation action runner by id **Slug:** `PAGERDUTY_GET_AUTOMATION_ACTION_RUNNER_BY_ID` Retrieves detailed information about a specific Automation Action Runner in PagerDuty. This endpoint allows users to fetch the configuration, status, and other relevant details of a Runner by providing its unique identifier. It's particularly useful for monitoring the health and settings of individual Runners, which are crucial components in PagerDuty's automated incident response system. This tool should be used when you need to inspect or verify the properties of a specific Runner, such as its connection status, associated scripts, or execution environment. It does not modify the Runner's configuration or trigger any actions; it's purely for information retrieval. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the Automation Action Runner to retrieve (e.g., 'P1RUNNER', 'PRUNNER123'). This ID is returned when creating a runner or can be obtained by listing all runners. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get automation actions runners **Slug:** `PAGERDUTY_GET_AUTOMATION_ACTIONS_RUNNERS` Lists all automation action runners in your PagerDuty account. Runners are the execution environments that perform automation actions during incident response. Each runner can be a Runbook Automation instance or a Sidecar runner. This endpoint returns details about each runner including its type, name, description, connection status (last_seen timestamp), and optionally the automation actions associated with it. Use this to monitor runner health, audit runner configurations, or select appropriate runners for automation workflows. Supports filtering by name and pagination for large result sets. Note: This endpoint requires PagerDuty Automation Actions license/entitlement. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `name` | string | No | Filter runners by name using case-insensitive substring matching. Returns only runners whose names contain this text. | | `limit` | integer | No | Maximum number of runners to return per page. If not specified, the API will use its default page size. | | `cursor` | string | No | Cursor for pagination. Use the cursor value returned in the previous response to fetch the next page of results. When omitted, returns the first page. | | `include` | array | No | Include additional related data in the response. Available option: 'associated_actions' - includes automation actions linked to each runner. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get automation action team by team id **Slug:** `PAGERDUTY_GET_AUTOMATION_ACTION_TEAM_BY_TEAM_ID` Retrieves detailed information about a specific team's association with an automation action in PagerDuty. This endpoint returns the details of how a particular team is linked to an automation action, which is useful for auditing access control, managing team permissions, and understanding which teams can execute specific automation actions. Use this endpoint when you need to verify or inspect the relationship between a specific team and an automation action, or when troubleshooting team-specific automation access and permissions. The response includes information about the team-action association that was created via the associate team endpoint. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `team_id` | string | Yes | The team ID | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get business services impacts **Slug:** `PAGERDUTY_GET_BUSINESS_SERVICES_IMPACTS` List Business Services sorted by impacted status. Returns all business services in the account, sorted with impacted services first, followed by non-impacted services. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `ids` | array | No | Optional list or comma-separated string of business service IDs to filter the results. Only impacts from these specific business services will be returned. Example: ['PSERVICE1', 'PSERVICE2'] or 'PSERVICE1,PSERVICE2'. | | `additional__fields` | string ("services.highest_impacting_priority" | "total_impacted_count") | No | Provides access to additional fields such as highest priority per business service and total impacted count. Choose 'services.highest_impacting_priority' to include the highest priority of incidents impacting each service, or 'total_impacted_count' to include the total number of impacted services. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get business services priority thresholds **Slug:** `PAGERDUTY_GET_BUSINESS_SERVICES_PRIORITY_THRESHOLDS` Retrieves the current priority threshold settings for all business services in PagerDuty. This endpoint allows users to fetch the configured thresholds that determine incident prioritization and escalation for each business service. It should be used when auditing or reviewing the current priority configurations across the organization's services. The tool provides a comprehensive view of how incidents are categorized and escalated based on their severity for different business services. It does not allow modification of these thresholds; for changes, a separate update endpoint would be required. #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get business service subscribers by id **Slug:** `PAGERDUTY_GET_BUSINESS_SERVICE_SUBSCRIBERS_BY_ID` Retrieves a list of subscribers for a specific business service in PagerDuty. This endpoint allows you to fetch all users or teams configured to receive notifications for incidents related to the specified business service. It's useful for auditing who is responsible for responding to issues within a particular service, or for managing notification settings at a service level. The endpoint returns read-only data and does not modify any configurations. Use this when you need to review or verify the current subscriber list for a business service, such as during incident response planning or service ownership reviews. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the business service. You can get this from listing business services or by creating a new business service. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get cache variable by id **Slug:** `PAGERDUTY_GET_CACHE_VARIABLE_BY_ID` Retrieves detailed information about a specific cache variable associated with a particular service within an event orchestration in PagerDuty. This endpoint allows you to access the current state and configuration of a cache variable, which can be crucial for understanding and troubleshooting event orchestration workflows. Use this when you need to inspect or verify the settings of a cache variable for a given service, such as during debugging or auditing processes. The endpoint provides read-only access and does not allow modification of the cache variable. Keep in mind that the response will only include information about the specified cache variable and will not provide a comprehensive view of all variables or the entire event orchestration configuration. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `service_id` | string | Yes | The service ID | | `cache_variable_id` | string | Yes | The ID of a Cache Variable. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get cache variables for service **Slug:** `PAGERDUTY_GET_CACHE_VARIABLES_FOR_SERVICE` Lists all cache variables configured for a Service Event Orchestration. Cache variables store dynamic event data that can be used in service-level routing and automation workflows. Returns detailed configurations including variable types (recent_value, trigger_event_count, or external_data), conditions for updates, enabled/disabled state, and audit metadata (created/updated timestamps and user references). Use cases: - Audit cache variable configurations for a service - Debug event processing and orchestration logic - Export service orchestration setup for documentation or backup - Verify cache variable states before making changes Requirements: - PagerDuty AIOps add-on or Advanced Event Orchestration tier - event_orchestrations:read scope - Team Manager or higher permissions - Service must have Event Orchestration enabled Note: Returns an empty array if no cache variables exist for the service orchestration. Each service orchestration can have up to 100 cache variables. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `service_id` | string | Yes | The ID of the PagerDuty service for which to retrieve cache variables. This is the unique identifier of the service in your PagerDuty account (e.g., 'P18JCJH'). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get escalation policy by id **Slug:** `PAGERDUTY_GET_ESCALATION_POLICY_BY_ID` Retrieves detailed information about a specific escalation policy in PagerDuty. This endpoint allows you to fetch the complete configuration of an escalation policy, including its name, description, escalation rules, and associated services. Use this when you need to review or audit an existing escalation policy's setup. It's particularly useful for understanding how incidents are being routed and escalated within your organization. This endpoint does not modify any data and is safe for frequent calls, but be mindful of rate limits. Note that it only provides information for a single policy; to list multiple policies, you would need a different endpoint. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The escalation policy ID (e.g., 'P3WFD7G'). This is the unique identifier for the escalation policy you want to retrieve. | | `include` | string ("services" | "teams" | "targets") | No | Optional parameter to expand related objects in the response. 'services': includes full service details; 'teams': includes full team details; 'targets': includes full user/schedule details for escalation targets with contact methods. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get event integrations by id **Slug:** `PAGERDUTY_GET_EVENT_INTEGRATIONS_BY_ID` Retrieves a list of integrations associated with a specific event orchestration in PagerDuty. This endpoint allows users to fetch all the integrations that are configured for a particular event orchestration, providing insights into how incidents are being routed and managed. It's useful for auditing the current setup of an event orchestration or when planning to modify the orchestration's integration configuration. The endpoint returns details about each integration, which may include integration types, configurations, and other relevant metadata. Use this when you need to review or analyze the integrations tied to a specific event orchestration for troubleshooting, reporting, or system optimization purposes. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get event orchestration by id **Slug:** `PAGERDUTY_GET_EVENT_ORCHESTRATION_BY_ID` Retrieves detailed information about a specific event orchestration in PagerDuty using its unique identifier. This endpoint allows users to fetch the configuration and settings of a particular event orchestration, which is crucial for understanding and analyzing how incidents are being managed and automated within the PagerDuty system. It should be used when you need to review or audit the setup of an event orchestration, such as its routing rules, filters, and associated services. The endpoint provides a comprehensive view of the orchestration but does not modify any settings. Keep in mind that access to this information may be restricted based on the user's permissions within the PagerDuty account. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier (UUID) of the Event Orchestration to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List cache variables for event orchestration **Slug:** `PAGERDUTY_GET_EVENT_ORCHESTRATION_CACHE_VARIABLES` Lists all cache variables configured for a specific Global Event Orchestration. Cache variables store dynamic data extracted from events, enabling complex routing rules and automation workflows based on event history and context. Returns up to 100 cache variables per orchestration with their configuration, conditions, enabled/disabled state, and metadata. Cache variable types: - recent_value: Stores CEF or raw event data - trigger_event_count: Counts events matching conditions - external_data: Stores data from external sources Use this to audit configurations, debug routing logic, or export orchestration settings for documentation. Requires Event Intelligence/Digital Operations plan or PagerDuty AIOps add-on, Advanced Event Orchestration pricing tier, API token with event_orchestrations:read scope, and Team Manager permissions or above. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier (UUID) of the Event Orchestration for which to list cache variables. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get event orchestration global **Slug:** `PAGERDUTY_GET_EVENT_ORCHESTRATION_GLOBAL` Get the Global Orchestration configuration for an Event Orchestration. Returns the global-level routing rules and configurations that process all events sent to this orchestration before they reach service-specific rules. The response includes rule sets (starting with 'start' set), catch-all actions, parent orchestration reference, and metadata. Use this to view or audit the global event routing logic for an orchestration. Scoped OAuth requires: `event_orchestrations.read` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get event orchestration integration **Slug:** `PAGERDUTY_GET_EVENT_ORCHESTRATION_INTEGRATION` Retrieves detailed information about a specific integration associated with an event orchestration in PagerDuty. This endpoint allows you to fetch the configuration and settings of a particular integration within the context of an event orchestration. Use this when you need to inspect or verify the setup of an integration, such as its type, configuration parameters, or connection status. The endpoint is particularly useful for troubleshooting integration issues or when you need to review the current state of an integration as part of your incident management workflow. Note that this endpoint only provides read access to the integration details and cannot be used to modify the integration. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | | `integration_id` | string | Yes | The ID of an Integration. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get extension schema by id **Slug:** `PAGERDUTY_GET_EXTENSION_SCHEMA_BY_ID` Retrieves a specific extension schema from PagerDuty by its unique identifier. Extension schemas are pre-defined templates that define how PagerDuty integrates with external systems (like webhooks, Slack, Amazon EventBridge, ServiceNow, etc.). Each schema contains configuration details, supported webhook event types (trigger, acknowledge, resolve, etc.), UI elements (icons, logos), and metadata about the integration. This endpoint returns the complete definition of a specific extension schema including its label, description, required configuration fields, send types, features, and addon information. Use this action when you need to understand the capabilities and configuration requirements of a specific integration type before creating an extension instance. The schema ID can be obtained from the list extension schemas endpoint. This is a read-only operation that doesn't modify any data. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the extension schema to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get impact by status page id **Slug:** `PAGERDUTY_GET_IMPACT_BY_STATUS_PAGE_ID` Retrieves detailed information about a specific impact level configuration on a PagerDuty status page. Impacts are predefined severity descriptors (such as 'Minor', 'Major', or 'Critical') that describe how business services are affected during incidents. This endpoint returns the configuration details for a specific impact level, including its ID, name, and description. Use this action when you need to understand the details of a particular impact level, such as when creating status page posts or analyzing how incidents are categorized. To get a list of all available impacts for a status page, use the 'Get Status Page Impacts By ID' action first. Note: This retrieves impact level metadata, not information about actual incidents affecting services. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page. You can get status page IDs from the 'Fetch Status Pages' action. | | `impact_id` | string | Yes | The ID of the status page impact. Impacts represent severity level descriptors (e.g., 'minor', 'major', 'critical') that describe how services are affected. You can get impact IDs from the 'Get Status Page Impacts By ID' action. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get incident alert details **Slug:** `PAGERDUTY_GET_INCIDENT_ALERT_DETAILS` Retrieves detailed information about a specific alert associated with a particular incident in PagerDuty. This endpoint is used when you need to access the properties and current state of an individual alert within the context of its parent incident. It's particularly useful for tracking the progression of an alert, understanding its current status, and gathering related metadata. The endpoint should be called when detailed information about a single alert is required, rather than for bulk operations or listing multiple alerts. Note that this endpoint focuses on retrieving data and does not modify the alert or incident. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `alert_id` | string | Yes | The id of the alert to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get incident log entries by id **Slug:** `PAGERDUTY_GET_INCIDENT_LOG_ENTRIES_BY_ID` Retrieves all log entries associated with a specific incident in PagerDuty. This endpoint provides a comprehensive history of actions, notifications, and status changes related to the incident. It should be used when detailed information about the lifecycle of an incident is needed, such as for post-incident reviews, auditing, or tracking the incident resolution process. The endpoint returns log entries in chronological order, allowing users to trace the incident's progression from creation to resolution. Note that the number of log entries returned may be large for long-running or complex incidents, so pagination might be necessary (though not specified in the given schema). #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `limit` | integer | No | The number of results per page. | | `since` | string | No | The start of the date range over which you want to search. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `until` | string | No | The end of the date range over which you want to search. | | `offset` | integer | No | Offset to start pagination search results. | | `include` | string ("incidents" | "services" | "channels" | "teams") | No | Additional related objects to include in the log entry response. - incidents: Include full incident details in each log entry - services: Include full service details in each log entry - channels: Include detailed channel information for each log entry - teams: Include full team details for log entries involving teams | | `time_zone` | string | No | Time zone in which results will be rendered. This will default to the account time zone. | | `is_overview` | boolean | No | If `true`, will return a subset of log entries that show only the most important changes to the incident. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get incident workflow action by id **Slug:** `PAGERDUTY_GET_INCIDENT_WORKFLOW_ACTION_BY_ID` Retrieves detailed information about a specific incident workflow action by its ID. An incident workflow action is a reusable automation step that can be used in incident workflows. This endpoint returns the action's metadata including its name, description, inputs, outputs, and configuration details. Use this when you need to: - Inspect the configuration and parameters of a workflow action - Understand what inputs an action requires before using it in a workflow - View the outputs an action produces - Verify action metadata like version, domain, and package information The action ID follows the format: 'domain_name:package_name:function_name:version' (e.g., 'pagerduty.com:slack:send-message:1'). This is a read-only operation that does not modify or execute the action. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the incident workflow action to retrieve. Format: 'domain:package:function:version' (e.g., 'pagerduty.com:aws:cloudwatch-query:1'). Use the list incident workflow actions endpoint to discover available action IDs. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get incident workflows **Slug:** `PAGERDUTY_GET_INCIDENT_WORKFLOWS` Lists all incident workflows configured in your PagerDuty account. Incident workflows are automated sequences of actions that execute during incident response to streamline processes like notifications, status updates, and integrations. This read-only endpoint retrieves workflow metadata including names, descriptions, associated teams, and optionally the workflow steps themselves. Use cases: - Browse available workflows to understand incident response automation - Find a specific workflow by name using the query filter - Audit which teams own which workflows - Retrieve workflow IDs for use with other workflow management actions Supports pagination and filtering. Use the 'include' parameter to fetch additional details like workflow steps or team information in a single request. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. Default is 25 if not specified. | | `query` | string | No | Search query to filter workflows by name. Returns only workflows whose names match this string. | | `total` | boolean | No | Whether to include the total count of workflows in the response. Set to true to get the total count, or false (default) for faster response times. See [PagerDuty Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for details. | | `offset` | integer | No | The offset to start pagination. Use 0 for the first page, then increment by the limit for subsequent pages. | | `include` | array | No | Additional details to include in the response. Use 'steps' to include workflow step details, or 'team' to include team information. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get incident workflows actions **Slug:** `PAGERDUTY_GET_INCIDENT_WORKFLOWS_ACTIONS` Retrieves a list of all available actions that can be used in incident workflows within PagerDuty. This endpoint provides information about the various automated tasks and responses that can be configured to streamline incident management processes. It should be used when setting up or modifying incident workflows to understand the range of actions available for automation. The endpoint returns details about each action, which may include its name, description, and any configurable parameters. This tool is particularly useful for developers and system administrators who are designing or optimizing their incident response procedures in PagerDuty. Note that while this endpoint retrieves action information, it does not execute or modify any actions itself. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The minimum of the `limit` parameter used in the request or the maximum request size of the API. | | `cursor` | string | No | Optional parameter used to request the "next" set of results from an API. The value provided here is most commonly obtained from the `next_cursor` field of the previous request. When no value is provided, the request starts at the beginning of the result set. | | `keyword` | string | No | If provided, only show actions tagged with the specified keyword | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get Jira Cloud account mappings **Slug:** `PAGERDUTY_GET_JIRA_CLOUD_ACCOUNT_MAPPINGS` Lists all account mappings between PagerDuty and Jira Cloud instances. Use this to retrieve the integration mappings that link PagerDuty accounts (by subdomain) to Jira Cloud instances (by base URL). This is useful for verifying configured integrations, auditing cross-platform connections, or managing Jira-PagerDuty sync configurations. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. Defaults to 25 if not specified. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See PagerDuty's Pagination Docs for more information. | | `offset` | integer | No | Offset to start pagination search results. Defaults to 0 if not specified. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get log entries **Slug:** `PAGERDUTY_GET_LOG_ENTRIES` Retrieves log entries from the PagerDuty system, providing a detailed history of events and actions related to incidents and system activities. This endpoint is crucial for auditing purposes, allowing users to track changes, responses, and other important events within their incident management workflow. It supports filtering by date range and specific incidents, making it useful for both broad overview analysis and detailed incident investigations. The endpoint uses pagination to manage large sets of log entries, ensuring efficient data retrieval and processing. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `since` | string | No | The start of the date range over which you want to search. Must be a valid ISO 8601 datetime string (e.g., '2024-01-15T10:00:00Z'). | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `until` | string | No | The end of the date range over which you want to search. Must be a valid ISO 8601 datetime string (e.g., '2024-01-15T23:59:59Z'). | | `offset` | integer | No | Offset to start pagination search results. | | `include` | string ("incidents" | "services" | "channels" | "teams") | No | Additional details to include in the response. Options: 'incidents' (full incident details), 'services' (full service details), 'channels' (channel information), 'teams' (team details). When specified, the corresponding objects will be expanded with complete information instead of just references. | | `team__ids` | array | No | An array of team IDs. Only results related to these teams will be returned. Account must have the `teams` ability to use this parameter. | | `time_zone` | string | No | Time zone in which results will be rendered. This will default to the account time zone. | | `is_overview` | boolean | No | If `true`, will return a subset of log entries that show only the most important changes to the incident. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get maintenance window by id **Slug:** `PAGERDUTY_GET_MAINTENANCE_WINDOW_BY_ID` Retrieves detailed information about a specific maintenance window in PagerDuty. This endpoint allows users to access the configuration, schedule, and status of a particular maintenance window using its unique identifier. It's useful for reviewing planned maintenance periods, verifying window settings, or checking the current status of a maintenance window. The endpoint should be used when detailed information about a single maintenance window is needed, rather than for listing all maintenance windows or creating new ones. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `include` | string ("teams" | "services" | "users") | No | Array of additional Models to include in response. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get oauth delegations revocation requests status **Slug:** `PAGERDUTY_GET_OAUTH_DELEGATIONS_REVOCATION_REQUESTS_STATUS` **DEPRECATED**: This endpoint is deprecated. The DELETE /oauth_delegations endpoint is now synchronous and completes immediately, eliminating the need to check revocation request status separately. Get the status of all OAuth delegations revocation requests for this account, specifically how many requests are still pending processing. OAuth delegations represent instances of app authorization (e.g., mobile app, Slack, Microsoft Teams) to access a PagerDuty account. This endpoint was previously used when deletion was asynchronous. **Access Requirements:** - Limited to account owners and admins only - Scoped OAuth requires: `oauth_delegations.read` **Note**: Since the DELETE operation is now synchronous, you should use the PAGERDUTY_DELETE_ALL_OAUTH_DELEGATIONS action directly, which returns the result immediately without needing to poll for status. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `requested_at_end` | string | No | The end of the date range over which you want to search for revocation requests. Must be a valid ISO 8601 datetime string (e.g., '2024-01-15T12:00:00Z'). If not specified, defaults to the current time. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get paused incident alerts **Slug:** `PAGERDUTY_GET_PAUSED_INCIDENT_ALERTS` Retrieves the most recent paused incident alerts from PagerDuty for a specified reporting period. This endpoint returns up to 5 of the most recent alerts that were triggered after being paused, and up to 5 of the most recent alerts that were resolved after being paused. Alerts can be paused by two mechanisms: - Auto-Pause Incident Notifications: PagerDuty's ML-based feature that automatically pauses notifications for transient alerts that typically auto-resolve - Event Orchestration Rules: User-configured rules that pause incident creation for predefined periods Use this endpoint to: - Monitor the effectiveness of Auto-Pause Incident Notifications - Review alerts that were paused and subsequently triggered or resolved - Audit pause behavior across services - Analyze patterns in paused alerts to optimize notification rules Note: This feature requires Digital Operations (legacy) or Enterprise Incident Management plans, or the AIOps add-on. Access without the required plan will result in a 403 Forbidden error. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `since` | string | No | The start of the date range over which you want to search, in ISO 8601 format (e.g., '2026-01-01T00:00:00Z'). If not specified, defaults to 30 days ago. | | `until` | string | No | The end of the date range over which you want to search, in ISO 8601 format (e.g., '2026-01-29T23:59:59Z'). If not specified, defaults to the current time. | | `service_id` | string | No | The ID of the service to filter paused incident alerts. Use this to limit results to alerts from a specific PagerDuty service. If not provided, returns alerts from all services. | | `suspended_by` | string | No | Filter alerts by the mechanism that suspended them. Currently only 'auto_pause' is supported, which filters for alerts suspended by the Auto-Pause Incident Notifications feature. If not specified, returns all paused alerts. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get post from status page by id **Slug:** `PAGERDUTY_GET_POST_FROM_STATUS_PAGE_BY_ID` Retrieves detailed information about a specific post on a PagerDuty status page. This endpoint allows you to fetch the content, timestamp, and any associated metadata for a particular update or message that has been posted to a status page. It's particularly useful for retrieving historical updates about incidents, maintenance notices, or general service status communications. Use this endpoint when you need to access or display the full details of a specific status update, such as when building a custom status page interface or integrating PagerDuty status updates into another system. Note that this endpoint only retrieves information for existing posts; it cannot be used to create, modify, or delete posts. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `include` | array | No | Array of additional Models to include in response. | | `post_id` | string | Yes | The ID of the Status Page Post. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get response plays **Slug:** `PAGERDUTY_GET_RESPONSE_PLAYS` **DEPRECATED**: This endpoint was deprecated and removed in June 2024. Response Plays have been replaced by Incident Workflows, which provide more robust and powerful automation capabilities. Accounts have been migrated to use Incident Workflows instead. If you need similar functionality, please use the Incident Workflows API endpoints: - List Incident Workflows: GET /incident_workflows - Get Incident Workflow: GET /incident_workflows/{id} Original functionality: This endpoint retrieved a list of response plays configured in the PagerDuty account. Response plays were predefined sets of actions that could be automatically executed when an incident occurred, helping to streamline and standardize incident response processes. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `query` | string | No | Filters the result, showing only the response plays whose name matches the query. | | `filter_for_manual_run` | boolean | No | When true, only response plays that can be run manually will be returned. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get rule from ruleset by id **Slug:** `PAGERDUTY_GET_RULE_FROM_RULESET_BY_ID` Retrieves detailed information about a specific rule within a PagerDuty ruleset. This endpoint allows users to fetch the configuration and settings of an individual rule, which is essential for understanding how incidents are being automated and managed. It should be used when detailed information about a particular rule's conditions, actions, or other properties is needed. This endpoint is particularly useful for auditing ruleset configurations, troubleshooting automation issues, or preparing to update rule settings. It does not modify any data and is safe for frequent use in monitoring or dashboard applications. However, it will not provide an overview of all rules in a ruleset or allow for rule modifications. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `rule_id` | string | Yes | The id of the Event Rule to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get schedules **Slug:** `PAGERDUTY_GET_SCHEDULES` Retrieves a list of all schedules from your PagerDuty account. This endpoint provides essential information about on-call rotations, helping teams manage and organize their incident response workflows. Use this when you need to view all existing schedules, such as during schedule audits, team restructuring, or when setting up integrations that require schedule IDs. The endpoint returns basic details for each schedule, which can be used to make further API calls for more specific information. Note that this endpoint does not provide the full details of each schedule's rotation patterns; for that, you would need to make additional API calls using the schedule IDs returned by this endpoint. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `query` | string | No | Filters the result, showing only the records whose name matches the query. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | | `include` | string ("schedule_layers") | No | Array of additional details to include. | | `time_zone` | string | No | Time zone in which results will be rendered. This will default to the current user"s time zone and then the account"s time zone. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get SCIM resource types **Slug:** `PAGERDUTY_GET_SCIM_RESOURCE_TYPES` Get SCIM resource types supported by PagerDuty's SCIM service provider. Returns metadata about available resource types (User, Group) including their endpoints, schemas, and names. Use this to discover which SCIM resources are supported by PagerDuty before performing SCIM provisioning operations. This follows the SCIM 2.0 protocol specification for ResourceTypes discovery. #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get SCIM schema by ID **Slug:** `PAGERDUTY_GET_SCIM_SCHEMA_BY_ID` Retrieves an individual SCIM schema definition by its unique identifier (ID). Returns the complete schema structure including all attribute definitions, data types, constraints, and metadata. Use this to understand the structure of SCIM resources like Users and Groups before creating or updating them, or to validate SCIM implementation compliance. Common schema IDs include User (urn:ietf:params:scim:schemas:core:2.0:User) and Group (urn:ietf:params:scim:schemas:core:2.0:Group). #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier for the SCIM schema. Common schema IDs include 'urn:ietf:params:scim:schemas:core:2.0:User' for User schema, 'urn:ietf:params:scim:schemas:core:2.0:Group' for Group schema, and 'urn:ietf:params:scim:schemas:extension:enterprise:2.0:User' for Enterprise User extension. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get SCIM service provider config **Slug:** `PAGERDUTY_GET_SCIM_SERVICE_PROVIDER_CONFIG` Retrieves the SCIM 2.0 Service Provider Configuration for PagerDuty. This endpoint returns the capabilities and features supported by PagerDuty's SCIM implementation, including support for PATCH, bulk operations, filtering, sorting, and authentication schemes. Use this to understand what SCIM operations are available before performing user provisioning or management tasks. #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get SCIM user **Slug:** `PAGERDUTY_GET_SCIM_USER` Retrieves detailed information about a specific user from PagerDuty's SCIM directory. Use this action when you need to fetch user profile information including display name, email, role, active status, job title, timezone, and license entitlements. This endpoint follows the SCIM 2.0 protocol standard for user provisioning and identity management. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the SCIM user to retrieve (e.g., 'AGLIHZ3ELN6IXOIPRP53SHRE7I'). This is the unique identifier for the user in the SCIM directory. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get service custom field values **Slug:** `PAGERDUTY_GET_SERVICE_CUSTOM_FIELD_VALUES` Retrieves the custom field values for a specific PagerDuty service. Use this when you need to fetch custom metadata or additional structured information associated with a service. Custom fields allow organizations to extend PagerDuty services with domain-specific data like cost centers, SLA tiers, or application versions. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the service to retrieve custom field values for. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get enablements for a service **Slug:** `PAGERDUTY_GET_SERVICE_ENABLEMENTS` Retrieves feature enablement settings for a specific PagerDuty service. Use this to check which features are enabled or disabled for a service, such as alert grouping or auto-pause notifications. This is useful when auditing service configurations or determining which capabilities are active on a service. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the service to retrieve feature enablement settings for (e.g., 'PG9JLO3'). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get service impacts by url slug **Slug:** `PAGERDUTY_GET_SERVICE_IMPACTS_BY_URL_SLUG` Retrieves service impacts for a specific status dashboard in PagerDuty. This endpoint allows users to fetch real-time information about how incidents or maintenance activities are affecting services displayed on a particular dashboard. It's useful for monitoring the current state of services, understanding ongoing issues, and assessing the overall health of systems represented in the specified dashboard. The endpoint should be used when you need to programmatically access up-to-date service impact data for a known status dashboard, enabling integration with other monitoring or reporting tools. Note that this endpoint only provides information for a single dashboard at a time and requires knowledge of the dashboard's URL slug. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `url_slug` | string | Yes | The `url_slug` for a status dashboard | | `additional__fields` | string ("services.highest_impacting_priority" | "total_impacted_count") | No | Provides access to additional fields such as highest priority per business service and total impacted count | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get severity for status page **Slug:** `PAGERDUTY_GET_SEVERITY_FOR_STATUS_PAGE` Retrieves detailed information about a specific severity level on a particular status page in PagerDuty. This endpoint is used to fetch the configuration and metadata associated with a severity, which is crucial for understanding how incidents are categorized and communicated on a status page. It provides insights into how different levels of service disruptions are represented and managed within the PagerDuty system. This tool is essential for developers and administrators who need to programmatically access or audit severity configurations on status pages, enabling them to ensure consistent incident communication across their organization. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page whose severity information you want to retrieve. | | `severity_id` | string | Yes | The ID of the specific severity level to retrieve. Severity levels categorize the impact of incidents or service disruptions (e.g., minor, major, critical, maintenance). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get specific post update status **Slug:** `PAGERDUTY_GET_SPECIFIC_POST_UPDATE_STATUS` Retrieves the updates for a specific post on a PagerDuty status page. This endpoint allows users to fetch the chronological list of updates made to a particular post, providing detailed information about how the status or information has changed over time. It's particularly useful for tracking the progression of an incident or maintenance event that has been communicated through a status page. The endpoint should be used when there's a need to review the history of updates for a specific status page post, such as during post-incident reviews or when compiling reports on communication effectiveness during incidents. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the Status Page. You can get this from the 'Fetch Status Pages' action or from the status_page.id field in post responses. | | `post_id` | string | Yes | The ID of the Status Page Post. You can get this from creating a post or listing posts on a status page. | | `reviewed_status` | string ("approved" | "not_reviewed") | No | Optional filter by the reviewed status of the Post Updates. Use 'approved' to see only approved updates or 'not_reviewed' to see only updates pending review. Leave empty to see all updates. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get status dashboard by id **Slug:** `PAGERDUTY_GET_STATUS_DASHBOARD_BY_ID` Retrieves detailed information about a specific status dashboard in PagerDuty. Status Dashboards represent user-defined views for the Status Dashboard product that are limited to specific Business Services. This endpoint fetches the configuration, components, and current status of a particular dashboard. **IMPORTANT**: This is an early-access feature that requires: - The X-EARLY-ACCESS header set to 'status-dashboards' - Specific account permissions or subscription tier - The Status Dashboard feature enabled on your PagerDuty account Use this endpoint when you need to retrieve details about a known status dashboard by its ID. The endpoint is read-only and does not modify any data. To list all available status dashboards, use the retrieve_status_dashboards_information action first to obtain valid dashboard IDs. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status dashboard to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get status for status page by id **Slug:** `PAGERDUTY_GET_STATUS_FOR_STATUS_PAGE_BY_ID` Retrieves the current status of a specific item on a PagerDuty status page. This endpoint is used to fetch up-to-date information about the operational state of a particular service or component listed on a status page. It's particularly useful for integrations that need to monitor or display the latest status of services to users or internal systems. The endpoint requires both the status page ID and the specific status item ID, allowing for precise querying of individual service statuses within a larger status page context. This tool should be used when you need to programmatically check the current state of a specific service on a PagerDuty status page, such as during incident management or for creating custom dashboards. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page whose status information you want to retrieve. | | `status_id` | string | Yes | The ID of the specific status to retrieve. A status represents a level of operational state for services on the status page (e.g., operational, degraded performance, partial outage, major outage). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get status page impacts by id **Slug:** `PAGERDUTY_GET_STATUS_PAGE_IMPACTS_BY_ID` Retrieves the list of impact level configurations available for a specific status page in PagerDuty. Impact levels are predefined severity descriptors (such as 'Minor', 'Major', 'Critical', or 'All Good') that describe how business services are affected during incidents. This endpoint returns the configuration metadata for all impact levels on a status page, including their IDs, names, and descriptions. Use this action when you need to understand what impact levels are available for categorizing service disruptions on a status page, such as when creating status page posts or analyzing incident severity options. Optionally filter by post type (incident or maintenance) to see impacts relevant to specific post types. Note: This retrieves impact level metadata/configurations, not information about actual ongoing incidents or service disruptions. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page. You can get status page IDs from the 'Fetch Status Pages' action. | | `post_type` | string ("incident" | "maintenance") | No | Optional filter to only return impacts associated with posts of a specific type: 'incident' for service disruption posts or 'maintenance' for scheduled maintenance posts. If omitted, returns all impacts regardless of post type. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get status page subscription **Slug:** `PAGERDUTY_GET_STATUS_PAGE_SUBSCRIPTION` Retrieves detailed information about a specific subscription associated with a particular status page in PagerDuty. This endpoint allows users to fetch subscription details such as the subscriber's contact information, notification preferences, and current subscription status. It should be used when you need to review or verify the details of an existing subscription for a status page. The endpoint is particularly useful for managing and auditing subscriber information, troubleshooting notification issues, or when updating subscription settings. Note that this endpoint only provides read access to subscription data and cannot be used to modify or create new subscriptions. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `subscription_id` | string | Yes | The ID of the Status Page subscription. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get tags by entity type **Slug:** `PAGERDUTY_GET_TAGS_BY_ENTITY_TYPE` Retrieves all entities of a specific type that are associated with a given tag. Use this when you need to find all users, teams, or escalation policies that have been tagged with a particular tag. The response will only include the entity type specified in the request (e.g., if entity_type is 'users', only the users array will be populated). This is useful for filtering and organizing resources by tags, or for auditing which resources are associated with specific categorization labels. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the tag resource. | | `limit` | integer | No | The number of results per page. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | | `entity_type` | string ("users" | "teams" | "escalation_policies") | Yes | Type of entity related with the tag. Valid values: users, teams, or escalation_policies. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get team members by id **Slug:** `PAGERDUTY_GET_TEAM_MEMBERS_BY_ID` Retrieves a list of all members associated with a specific team in PagerDuty. This endpoint is useful for obtaining detailed information about the composition of a team, including user IDs, names, roles, and contact information of team members. It should be used when you need to review or audit team membership, update on-call rotations, or gather information for reporting purposes. The endpoint does not modify team membership; it only provides read access to the current team roster. Keep in mind that the response may be paginated for teams with a large number of members. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the team for which to list members. | | `limit` | integer | No | The number of results per page. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | | `include` | string ("users") | No | Include additional information in the response. Use 'users' to include full user details for each team member. If omitted, only basic user references are returned. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get team notification subscriptions **Slug:** `PAGERDUTY_GET_TEAM_NOTIFICATION_SUBSCRIPTIONS` Retrieves the notification subscriptions for a specific team in PagerDuty. This endpoint allows you to fetch detailed information about how a team is configured to receive notifications for various events and incidents. It's particularly useful for auditing a team's notification settings, understanding their alert preferences, and ensuring that the right people are notified at the right time. The endpoint should be used when you need to review or analyze a team's current notification setup, but it won't allow you to modify these settings directly. Keep in mind that the response may include sensitive information about team members and their notification preferences, so use this endpoint judiciously and in compliance with your organization's data privacy policies. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the team whose notification subscriptions you want to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get teams associated with action id **Slug:** `PAGERDUTY_GET_TEAMS_ASSOCIATED_WITH_ACTION_ID` Retrieves the list of teams associated with a specific automation action in PagerDuty. This endpoint is useful for understanding which teams are responsible for or have access to a particular automated process in the incident management workflow. It can be used to audit team assignments, manage access control, or gather information for reporting purposes. The endpoint returns only the teams linked to the specified automation action and does not provide details about the action itself or other related resources. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the automation action to retrieve teams for. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get template by id **Slug:** `PAGERDUTY_GET_TEMPLATE_BY_ID` Retrieves detailed information about a specific template in PagerDuty by its unique identifier. This endpoint is used to access the configuration and settings of a pre-defined template, which can include incident response procedures, notification rules, and other standardized actions. It's particularly useful when you need to review or reference an existing template for incident management purposes. The endpoint returns comprehensive data about the template, but does not modify or create new templates. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get the service orchestration for a service **Slug:** `PAGERDUTY_GET_THE_SERVICE_ORCHESTRATION_FOR_A_SERVICE` Get a Service Orchestration. A Service Orchestration allows you to create a set of Event Rules. The Service Orchestration evaluates Events sent to this Service against each of its rules, beginning with the rules in the "start" set. When a matching rule is found, it can modify and enhance the event and can route the event to another set of rules within this Service Orchestration for further processing. For more information see the [API Concepts Document](../../api-reference/ZG9jOjI3NDc5Nzc-api-concepts#event-orchestrations) Scoped OAuth requires: `services.read` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `include` | string ("migrated_metadata") | No | Optional parameter to include additional metadata. Use 'migrated_metadata' to include migration information (migrated_at, migrated_by, migrated_from, migrated_status, migrated_via) for orchestrations that were converted from legacy Event Rules. | | `service_id` | string | Yes | The ID of the PagerDuty service to retrieve the orchestration configuration for. You can find service IDs by listing services or from the service's page URL in the PagerDuty web app. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get user notification subscriptions **Slug:** `PAGERDUTY_GET_USER_NOTIFICATION_SUBSCRIPTIONS` Lists notification subscriptions for a specific PagerDuty user. Returns subscriptions to various entities like business services and incidents that the user has subscribed to for receiving notifications. Use this to audit which resources a user is monitoring, troubleshoot notification issues, or manage a user's subscription preferences. The response includes subscription type (business_service, incident), subscribable IDs, and pagination details (limit, offset, more, total). #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The PagerDuty user ID to retrieve notification subscriptions for. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get user session by type **Slug:** `PAGERDUTY_GET_USER_SESSION_BY_TYPE` Retrieves detailed information about a specific user session in PagerDuty. This endpoint allows you to fetch session-related data for a particular user, filtered by session type and identified by a unique session ID. It's useful for monitoring user activity, troubleshooting authentication issues, or auditing system access. The endpoint returns data about the specified session, which may include creation time, last activity timestamp, expiration time, and other relevant session attributes. It should be used when detailed information about a user's specific session is required, but it does not provide information about other sessions or general user account details. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The PagerDuty user ID whose session information will be retrieved. | | `type` | string | Yes | The session type. Must be "browser" for browser-based sessions. | | `session_id` | string | Yes | The unique identifier of the specific session to retrieve. Can be obtained from the get_user_sessions_by_id action. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get user sessions by id **Slug:** `PAGERDUTY_GET_USER_SESSIONS_BY_ID` Retrieves all active sessions for a specific user in PagerDuty. This endpoint allows you to fetch information about a user's current login sessions, which can be useful for auditing, security monitoring, or managing user access. It provides details such as session start times, device information, and IP addresses for each active session. Use this endpoint when you need to track user activity, investigate potential security issues, or manage concurrent logins. Note that this endpoint only returns information about active sessions and does not provide historical session data or the ability to modify sessions. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user whose active sessions you want to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get user status update notification rules **Slug:** `PAGERDUTY_GET_USER_STATUS_UPDATE_NOTIFICATION_RULES` Retrieves all status update notification rules for a specific user in PagerDuty. Returns a list of all notification rules that determine how the user receives notifications about incident status updates. Each rule specifies a contact method (email, SMS, or phone) to be used for sending status update notifications. Common use cases: - View all configured status update notification rules for a user - Audit user notification preferences and contact methods - Check which contact methods are set up for status updates - Verify notification configuration before modifying rules The response includes the total count of rules and detailed information about each rule including the associated contact method (with email address or phone number when included). #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `include` | array | No | Optional array of additional details to include. Use 'contact_methods' to include full contact method details (email address, phone number, enabled status, etc.) in the response for each notification rule. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get webhook subscription by id **Slug:** `PAGERDUTY_GET_WEBHOOK_SUBSCRIPTION_BY_ID` Retrieves detailed information about a specific webhook subscription in PagerDuty. This endpoint allows you to fetch the configuration and status of a webhook subscription, including its delivery method, subscribed events, and any applied filters. Use this when you need to review or verify the settings of an existing webhook subscription, such as checking which events it's configured to receive or confirming its current status. The endpoint provides a snapshot of the subscription's configuration but does not include historical data about past webhook deliveries or failures. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get workflow integration **Slug:** `PAGERDUTY_GET_WORKFLOW_INTEGRATION` Get details about a Workflow Integration. Scoped OAuth requires: `workflow_integrations.read` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Get workflow integration connection **Slug:** `PAGERDUTY_GET_WORKFLOW_INTEGRATION_CONNECTION` Get details about a Workflow Integration Connection. Scoped OAuth requires: `workflow_integrations:connections.read` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the workflow integration connection to retrieve. | | `integration_id` | string | Yes | The ID of the Workflow Integration type (e.g., 'http-api', 'slack', 'github'). Workflow integrations enable authentication with external tools for incident workflows. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Install add on endpoint **Slug:** `PAGERDUTY_INSTALL_ADD_ON_ENDPOINT` This endpoint allows you to install a new add-on to your PagerDuty account, enhancing its functionality with custom integrations. Add-ons can be either full-page or incident-specific, providing additional context or tools within the PagerDuty interface. Use this endpoint when you want to integrate external resources or custom dashboards into your PagerDuty workflow. The add-on must have a secure HTTPS source URL and a unique name within your account. Note that while you can install multiple add-ons, each must serve a distinct purpose and have a different name and source URL. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `addon` | object | Yes | The addon object containing name, src, and optional type fields | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Invoke automation action by ID **Slug:** `PAGERDUTY_INVOKE_AUTOMATION_ACTION_BY_ID` Invokes a specific automation action in PagerDuty, associating it with a particular incident. This endpoint allows you to trigger pre-defined automated tasks or workflows within the PagerDuty incident management system. It's particularly useful for executing custom actions or scripts in response to specific incidents, enhancing the incident response process. The action is identified by its unique ID, and the invocation must be linked to an existing incident through its incident ID. This endpoint should be used when you need to programmatically execute automation actions as part of your incident management workflow or integration with other systems. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the automation action to invoke. This is the ID of the automation action that you want to execute. | | `invocation__metadata__incident__id` | string | Yes | The PagerDuty incident ID to associate with this automation action invocation. This links the automation action execution to a specific incident for tracking and context. Format: typically starts with 'P' followed by alphanumeric characters (e.g., 'PABC123'). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List all workflow integration connections **Slug:** `PAGERDUTY_LIST_ALL_WORKFLOW_INTEGRATION_CONNECTIONS` List all Workflow Integration Connections. Scoped OAuth requires: `workflow_integrations:connections.read` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `name` | string | No | Filter connections by partial name match (case-insensitive). | | `limit` | integer | No | The maximum number of connections to return per page. If not specified, defaults to 10. | | `cursor` | string | No | Optional parameter used to request the "next" set of results from an API. The value provided here is most commonly obtained from the `next_cursor` field of the previous request. When no value is provided, the request starts at the beginning of the result set. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List automation action details **Slug:** `PAGERDUTY_LIST_AUTOMATION_ACTION_DETAILS` This endpoint retrieves a list of automation actions configured in the PagerDuty account. Automation actions are predefined tasks or operations that can be executed automatically in response to incidents or other triggers. The endpoint allows users to view all available automation actions, which can be useful for auditing, managing, or integrating these actions into other workflows. It supports pagination for handling large sets of actions and can include related information about associated services and teams. Use this endpoint when you need to review, inventory, or programmatically access the automation capabilities within your PagerDuty environment. Note that this endpoint only provides information about existing actions and does not create, modify, or execute the actions themselves. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `name` | string | No | Filters results to include the ones matching the name (case insensitive substring matching) | | `limit` | integer | No | The minimum of the `limit` parameter used in the request or the maximum request size of the API. | | `cursor` | string | No | Optional parameter used to request the "next" set of results from an API. The value provided here is most commonly obtained from the `next_cursor` field of the previous request. When no value is provided, the request starts at the beginning of the result set. | | `team_id` | string | No | Filters results to include the ones associated with the specified team. | | `runner_id` | string | No | Filters results to include the ones linked to the specified runner. Specifying the value `any` filters results to include the ones linked to runners only, thus omitting the results not linked to runners. | | `service_id` | string | No | Filters results to include the ones associated with the specified service | | `action_type` | string ("script" | "process_automation") | No | Filters results to include the ones matching the specified action type | | `classification` | string ("diagnostic" | "remediation") | No | Filters results to include the ones matching the specified classification (aka category) | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List extension schemas **Slug:** `PAGERDUTY_LIST_EXTENSION_SCHEMAS` Retrieves all available extension schemas from the PagerDuty API. This endpoint allows users to fetch custom schema extensions that have been defined for their PagerDuty account. Extension schemas are used to add custom data structures or validation rules to the standard API schema, enabling more flexible and tailored data management. This tool is particularly useful when you need to understand the custom data fields or structures that have been added to your PagerDuty implementation. It does not create, modify, or delete extension schemas; it only provides a read-only view of the existing schemas. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List field options on a custom field **Slug:** `PAGERDUTY_LIST_FIELD_OPTIONS_ON_A_CUSTOM_FIELD` Lists all field options for a custom field on an incident type. Field options represent the selectable values for multi-value or dropdown custom fields in PagerDuty. This action returns all available options that users can select when categorizing or tagging incidents with this custom field. **Prerequisites:** 1. A valid incident type ID or name (use PAGERDUTY_LIST_INCIDENT_TYPES) 2. A valid custom field ID for that incident type (use PAGERDUTY_LIST_INCIDENT_TYPE_CUSTOM_FIELDS) 3. The custom field should be of type 'multi_value' or 'multi_value_fixed' to support options **Note:** This is an Early Access endpoint requiring the `custom_fields.read` OAuth scope. The X-EARLY-ACCESS header with value 'analytics-v2' is automatically included. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field_id` | string | Yes | The ID of the custom field to list options for. Use LIST_INCIDENT_TYPE_CUSTOM_FIELDS to find valid field IDs for an incident type. | | `type_id_or_name` | string | Yes | The ID or name of the Incident Type. Use LIST_INCIDENT_TYPES to find valid incident type IDs or names. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List incident status update subscribers **Slug:** `PAGERDUTY_LIST_INCIDENT_STATUS_UPDATE_SUBSCRIBERS` Retrieves a list of subscribers to status updates for a specific incident in PagerDuty. This endpoint allows you to see all users or services that are currently subscribed to receive notifications about status changes for the given incident. It's useful for understanding who is being kept informed about the incident's progress. This tool should be used when you need to review or audit the notification list for an incident, ensuring that all necessary stakeholders are included. It does not modify the subscriber list; for adding or removing subscribers, separate endpoints would be required. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident to retrieve status update subscribers for (e.g., 'Q1LM34T0WT52EL') | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List incident type custom fields **Slug:** `PAGERDUTY_LIST_INCIDENT_TYPE_CUSTOM_FIELDS` List the custom fields for an incident type. Custom Fields (CF) are a feature which will allow customers to extend Incidents with their own custom data, to provide additional context and support features such as customized filtering, search and analytics. Custom Fields can be applied to different incident types. > ### Early Access > This endpoint is in Early Access and may change at any time. You must pass in the X-EARLY-ACCESS header to access it. Scoped OAuth requires: `custom_fields.read` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `include` | string ("field_options") | No | Array of additional details to include. | | `type_id_or_name` | string | Yes | The ID or name of the Incident Type. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List incident types **Slug:** `PAGERDUTY_LIST_INCIDENT_TYPES` List the available incident types Incident Types are a feature which will allow customers to categorize incidents, such as a security incident, a major incident, or a fraud incident. These can be filtered by enabled or disabled types. > ### Early Access > This endpoint is in Early Access and may change at any time. You must pass in the X-EARLY-ACCESS header to access it. For more information see the [API Concepts Document](../../api-reference/ZG9jOjI3NDc5Nzc-api-concepts#incidentType) Scoped OAuth requires: `incident_types.read` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `filter` | string ("enabled" | "disabled" | "all") | No | Filters the list of incident types based on their `enabled` state. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List licenses **Slug:** `PAGERDUTY_LIST_LICENSES` Lists all licenses for the PagerDuty account, showing current usage and available allocations. This endpoint retrieves license information including: - License name and type (e.g., "Enterprise Incident Management (Full User)") - Current allocated users (current_value) - Available license allocations (allocations_available) - Valid user roles for each license type - Role group classification (FullUser, Stakeholder, etc.) Use this to: - Check available license allocations before creating users - Audit license usage and availability - Understand which roles are valid for each license type - Monitor license consumption across the account No parameters required - returns all licenses for the authenticated account. #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List SCIM schemas **Slug:** `PAGERDUTY_LIST_SCIM_SCHEMAS` Retrieves all SCIM schemas supported by the PagerDuty service provider. Returns a list of schema definitions including User, Group, and Enterprise User Extension schemas with their complete attribute structures, data types, and constraints. Use this to discover available SCIM schemas before creating or updating resources. #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List SCIM users **Slug:** `PAGERDUTY_LIST_SCIM_USERS` Lists users via the SCIM (System for Cross-domain Identity Management) API endpoint. Use when you need to retrieve user information in SCIM format, typically for identity provider integrations or user provisioning workflows. Supports pagination via startIndex and count parameters, and filtering by userName or externalId. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `count` | integer | No | Specifies the desired maximum number of query results per page. Used to limit the number of users returned in a single response. Must be a positive integer. | | `filter` | string | No | A filter expression to apply to the query. The only supported filters are by userName and externalId. Use SCIM filter syntax, for example: 'userName eq "user@example.com"' or 'externalId eq "12345"'. | | `startIndex` | integer | No | The 1-based index of the first result. Used for pagination to specify which page of results to retrieve. Must be a positive integer. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List service custom fields **Slug:** `PAGERDUTY_LIST_SERVICE_CUSTOM_FIELDS` Lists all custom fields available for services in PagerDuty. This endpoint returns a list of custom fields that can be used to add structured metadata to services. Custom fields allow teams to categorize and organize services with additional attributes beyond the standard service properties. Use this action when you need to discover available custom fields before setting or updating custom field values on services. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `include` | array | No | Array of additional details to include. Use 'field_options' to include the available options for each custom field. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List supporting service impacts **Slug:** `PAGERDUTY_LIST_SUPPORTING_SERVICE_IMPACTS` Retrieves information about the impacts of supporting services on a specific business service in PagerDuty. This endpoint is used to understand the relationships and dependencies between a primary business service and its supporting services, along with the potential impacts these relationships may have on incident management and service reliability. It's particularly useful for assessing the cascading effects of incidents across interconnected services and for proactive risk management. The endpoint should be used when analyzing service dependencies, planning incident response strategies, or evaluating the overall resilience of your service infrastructure. Note that this endpoint focuses on impact information and may not provide real-time incident data or detailed metrics about the services themselves. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the business service to retrieve supporting service impacts for. | | `ids` | string | No | Optional comma-separated list of supporting service IDs to filter the results. Only impacts from these specific supporting services will be returned. | | `additional__fields` | string ("services.highest_impacting_priority" | "total_impacted_count") | No | Provides access to additional fields such as highest priority per business service and total impacted count | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List templates **Slug:** `PAGERDUTY_LIST_TEMPLATES` Retrieves a list of templates available in the PagerDuty system. Templates are pre-defined configurations used for creating alerts, notifications, and other automated processes within PagerDuty. This endpoint should be used when you need to view or manage the existing templates in your PagerDuty account. It provides an overview of all templates, which can be useful for auditing, updating, or selecting templates for use in incident management workflows. The endpoint does not create, modify, or delete templates; it is solely for retrieving template information. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `query` | string | No | Template name or description to search | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | | `sort_by` | string ("name" | "name:asc" | "name:desc" | "created_at" | "created_at:asc" | "created_at:desc") | No | Used to specify both the field you wish to sort the results on (name/created_at), as well as the direction (asc/desc) of the results. The sort_by field and direction should be separated by a colon. Sort direction defaults to ascending. | | `template_type` | string | No | Filters templates by type. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List workflow integration connections **Slug:** `PAGERDUTY_LIST_WORKFLOW_INTEGRATION_CONNECTIONS` List all workflow integration connections for a specific workflow integration. Workflow integration connections represent configured instances of external tools (like AWS, Slack, HTTP APIs) that can be used in incident workflows. This action retrieves all connections associated with a particular integration type. Scoped OAuth requires: `workflow_integrations:connections.read` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `name` | string | No | Filter connections by partial name match (case-insensitive). | | `limit` | integer | No | The maximum number of connections to return per page. If not specified, defaults to 10. | | `cursor` | string | No | Pagination cursor for retrieving the next set of results. Obtain this value from the 'next_cursor' field of a previous response. Omit this parameter to start from the beginning. | | `integration_id` | string | Yes | The ID of the workflow integration to list connections for. Common values include 'http-api' for custom HTTP/web API connections. Use the LIST_WORKFLOW_INTEGRATIONS action to discover available integration IDs. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### List workflow integrations **Slug:** `PAGERDUTY_LIST_WORKFLOW_INTEGRATIONS` List available Workflow Integrations. Scoped OAuth requires: `workflow_integrations.read` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The minimum of the `limit` parameter used in the request or the maximum request size of the API. | | `cursor` | string | No | Optional parameter used to request the "next" set of results from an API. The value provided here is most commonly obtained from the `next_cursor` field of the previous request. When no value is provided, the request starts at the beginning of the result set. | | `include_deprecated` | boolean | No | Whether to include deprecated Integrations in the response. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Manage cache variables for event service **Slug:** `PAGERDUTY_MANAGE_CACHE_VARIABLES_FOR_EVENT_SERVICE` Creates a cache variable for a service event orchestration. Cache variables store temporary event data for use in orchestration rules. Requires Advanced Event Orchestration tier and Manager role. Configuration types: - recent_value: Stores latest value from event field (requires source, regex) - trigger_event_count: Counts matching events in time window (requires ttl_seconds) - external_data: Stores API-provided data (requires data_type, ttl_seconds) Use conditions to control updates. Reference in rules as cache_var.variable_name. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `service_id` | string | Yes | The ID of the PagerDuty service for which to create a cache variable (e.g., 'P18JCJH'). This service must have an event orchestration configured. | | `cache__variable__id` | string | No | The ID of the cache variable. This is typically auto-generated by PagerDuty and should not be provided when creating a new cache variable. | | `cache__variable__name` | string | Yes | The name of the cache variable (required). This should be a descriptive identifier for the variable, such as 'recent_alert_count' or 'last_error_message'. | | `cache__variable__disabled` | boolean | No | Whether the cache variable is disabled. When true, the cache variable will not be evaluated or updated by matching events. Defaults to false (enabled) | | `cache__variable__conditions` | array | No | Optional list of PCL condition expressions. Each condition is evaluated to check if an event should update this cache variable. The cache variable is updated if ANY of these conditions match (OR logic). Example: [{'expression': 'event.severity matches "critical"'}, {'expression': 'event.source matches "api"'}] | | `cache__variable__created__at` | string | No | The date/time the object was created. | | `cache__variable__updated__at` | string | No | The date/time the object was last updated. | | `cache__variable__configuration` | object | Yes | Configuration object for the cache variable (required). Must include a 'type' field with one of: 'recent_value' (stores the most recent value from an event field, requires 'source' field), 'trigger_event_count' (counts matching events, requires 'ttl_seconds' field), or 'external_data' (stores data from external API calls, requires 'data_type' and 'ttl_seconds' fields). Example: {'type': 'recent_value', 'source': 'event.summary'} or {'type': 'trigger_event_count', 'ttl_seconds': 3600} | | `cache__variable__created__by__id` | string | No | ID of the user who created the cache variable (read-only) | | `cache__variable__updated__by__id` | string | No | ID of the user who last updated the cache variable (read-only) | | `cache__variable__created__by__self` | string | No | The API show URL at which the object is accessible | | `cache__variable__created__by__type` | string | No | A string that determines the schema of the object. This must be the standard name for the entity, suffixed by `_reference` if the object is a reference. | | `cache__variable__updated__by__self` | string | No | The API show URL at which the object is accessible | | `cache__variable__updated__by__type` | string | No | A string that determines the schema of the object. This must be the standard name for the entity, suffixed by `_reference` if the object is a reference. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Merge source incidents into target incident **Slug:** `PAGERDUTY_MERGE_SOURCE_INCIDENTS_INTO_TARGET_INCIDENT` Merges multiple source incidents into a target incident in PagerDuty's incident management system. This endpoint allows users to consolidate related or duplicate incidents into a single, primary incident for streamlined management and resolution. The operation combines the specified source incidents into the target incident identified by the URL path, marking the source incidents as resolved. This tool should be used when multiple incidents are determined to be part of the same underlying issue or when consolidating incident management efforts. It's particularly useful for reducing noise and focusing on the root cause of related issues. Note that this action is irreversible, so care should be taken to ensure that the incidents are truly related before merging. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the target incident that will receive the merged incidents (e.g., 'Q1LM34T0WT52EL'). This incident will remain open after the merge. | | `source_incidents` | array | Yes | The source incidents that will be merged into the target incident and automatically resolved. Each incident reference must include an 'id' and 'type' field. Maximum 1000 alerts total across all incidents. Only mergeable incidents (those with alerts or manually created) can be merged. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Migrate integration between orchestrations **Slug:** `PAGERDUTY_MIGRATE_INTEGRATION_BETWEEN_ORCHESTRATIONS` This endpoint facilitates the migration of an integration from one event orchestration to another within PagerDuty. It allows users to reassign an existing integration to a different event orchestration, maintaining the integration's configuration while updating its association. This operation is useful when restructuring event management workflows or optimizing incident routing. The endpoint should be used when there's a need to change how a specific integration interacts with PagerDuty's event processing system. It's important to note that this process only changes the association and does not modify the integration's settings or connected external services. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | | `source_id` | string | Yes | The ID of the Event Orchestration you"ll be moving the Integration away from | | `source_type` | string ("orchestration") | Yes | The type of of the `source_id` object | | `integration_id` | string | Yes | The ID of the Integration you"ll be moving | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Modify entity tags **Slug:** `PAGERDUTY_MODIFY_ENTITY_TAGS` Add and/or remove tags from a PagerDuty entity (user, team, or escalation policy) in a single operation. This action modifies the tags associated with a specific entity. You can: - Add tags by label (creates new tags if they don't exist) - Add tags by ID reference (links existing tags) - Remove tags by ID reference - Perform add and remove operations simultaneously Tags are useful for categorizing and organizing PagerDuty resources, enabling easier searching and filtering. Supported entity types: - users: Tag individual users - teams: Tag teams (requires Teams feature) - escalation_policies: Tag escalation policies Note: Creating new tags requires appropriate permissions. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the specific entity (user, team, or escalation policy) to modify tags for. | | `add` | array | No | Array of tags and/or tag references to add to the entity. For elements with type `tag_reference`, the tag with the corresponding `id` is added to the entity. For elements with type `tag`, if there is an existing tag with the given label that tag is added to the entity. If there is no existing tag with that label and the user has permission to create tags, a new tag is created with that label and assigned to the entity. | | `remove` | array | No | Array of tag references to remove from the entity. | | `entity_type` | string ("users" | "teams" | "escalation_policies") | Yes | The type of PagerDuty entity to modify tags for. Must be one of: "users", "teams", or "escalation_policies". | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Ping webhook subscription **Slug:** `PAGERDUTY_PING_WEBHOOK_SUBSCRIPTION` The PingWebhookSubscription endpoint sends a test POST request to a specified webhook subscription in your PagerDuty account. This tool is used to verify that a webhook subscription is correctly configured and can receive notifications. It's particularly useful after setting up a new webhook subscription or when troubleshooting integration issues. The endpoint doesn't modify any data but simulates a real webhook delivery, allowing you to confirm that your systems can properly receive and process PagerDuty webhooks. Note that this tool only tests the delivery mechanism and doesn't validate the processing of specific event types on your end. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the webhook subscription to ping. This ID can be obtained from the list webhook subscriptions endpoint. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post account subscription for business service **Slug:** `PAGERDUTY_POST_ACCOUNT_SUBSCRIPTION_FOR_BUSINESS_SERVICE` This endpoint creates or updates an account subscription for a specific business service in PagerDuty. It allows users to manage subscription settings, such as notification preferences or service-level agreements, for a particular business service identified by its unique ID. Use this endpoint when you need to set up new subscription configurations or modify existing ones for a business service. The endpoint is particularly useful for automating subscription management across multiple business services or integrating subscription updates with other systems. Note that this operation may affect billing or service access, so it should be used carefully and with proper authorization. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post alert grouping settings **Slug:** `PAGERDUTY_POST_ALERT_GROUPING_SETTINGS` Creates a new Alert Grouping Setting in PagerDuty, defining how alerts will be automatically grouped into incidents based on specified configurations. This endpoint allows users to set up intelligent alert grouping rules, improving incident management efficiency by reducing noise and consolidating related alerts. It's particularly useful for teams looking to streamline their incident response process and minimize alert fatigue. The setting can be applied to one or multiple services, with the option to use content-based or intelligent grouping algorithms. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `alert__grouping__setting__id` | string | No | The unique identifier of the alert grouping setting. This is auto-generated by PagerDuty and should not be manually specified in POST requests. Leave this field empty/null. | | `alert__grouping__setting__name` | string | No | An optional short-form name for the alert grouping setting (e.g., 'Production Time-Based Grouping'). This provides a human-readable label for easy identification. It is not intended to be a unique identifier. Maximum recommended length: 100 characters. | | `alert__grouping__setting__type` | string ("content_based" | "content_based_intelligent" | "intelligent" | "time") | No | The type of alert grouping to use. Options are: 'time' (groups alerts within a time window), 'intelligent' (uses ML to group related alerts), 'content_based' (groups based on matching field values), or 'content_based_intelligent' (combines content matching with intelligent grouping). The type determines which config parameters are required. | | `alert__grouping__setting__config` | object | No | Configuration object for the alert grouping. Structure depends on the 'type' field. For 'time' grouping: {'timeout': }. For 'content_based' or 'content_based_intelligent': {'fields': [], 'aggregate': 'any' or 'all', 'time_window': } where fields and aggregate are required. For 'intelligent': {'time_window': } or empty. Time window values must be between 300-3600 seconds, or 86400 for content_based only. Set to null/omit time_window to use the recommended default. | | `alert__grouping__setting__services` | array | No | Required. An array of service references (each with 'id' and optionally 'type') that this AlertGroupingSetting applies to. Format: [{'id': 'SERVICE_ID', 'type': 'service_reference'}]. Note: content_based_intelligent type allows only ONE service in the array, while other types can have multiple services. | | `alert__grouping__setting__created__at` | string | No | The ISO8601 date/time when the AlertGroupingSetting was created. This is a read-only field and should not be provided in POST requests. | | `alert__grouping__setting__description` | string | No | An optional detailed description explaining the purpose and configuration of this alert grouping setting. Use this to document why this grouping rule exists and what alerts it's designed to group together. Maximum recommended length: 1000 characters. | | `alert__grouping__setting__updated__at` | string | No | The ISO8601 date/time when the AlertGroupingSetting was last updated. This is a read-only field and should not be provided in POST requests. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post analytic metrics on escalation policies **Slug:** `PAGERDUTY_POST_ANALYTIC_METRICS_ON_ESCALATION_POLICIES` Retrieves and aggregates analytics metrics for incidents related to escalation policies in PagerDuty. This endpoint allows for detailed filtering and customization of incident data, enabling users to analyze trends, performance, and patterns in their incident management process. It's particularly useful for generating reports, identifying areas for improvement, and understanding the effectiveness of escalation policies over time. The endpoint supports various filtering options, time zone specifications, and time-based aggregation, making it a powerful tool for operational insights and decision-making in incident management. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `order` | string ("asc" | "desc") | No | The order in which the results were sorted; asc for ascending, desc for descending. | | `order_by` | string | No | The column that was used for ordering the results. | | `time_zone` | string | No | The time zone to use for the results and grouping. Must be in tzdata format. See list of accepted values [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). | | `aggregate_unit` | string ("day" | "week" | "month") | No | The time unit to aggregate metrics by. If no value is provided, the metrics will be aggregated for the entire period. | | `filters__major` | boolean | No | A boolean flag including whether results should contain *only* [major incidents](https://support.pagerduty.com/docs/operational-reviews#major-incidents), or exclude major incidents. If no value is provided all incidents will be included. | | `filters__urgency` | string ("high" | "low") | No | Any incidents whose urgency does not match the provided string will be omitted from the results. | | `filters__team__ids` | array | No | An array of team IDs. Only incidents related to these teams will be included in the results. If omitted, all teams the requestor has access to will be included in the results. | | `filters__service__ids` | array | No | An array of service IDs. Only incidents related to these services will be included in the results. If omitted, all services the requestor has access to will be included in the results. | | `filters__priority__ids` | array | No | An array of priority IDs. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__priority__names` | array | No | An array of user-defined priority names. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__created__at__end` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at greater than or equal to this value will be omitted from the results. The maximum supported time range in conjunction with created_at_start is one year. | | `filters__pd__advance__used` | boolean | No | If true, only incidents where PD Advance was used will be included in the results, and vice versa. If omitted, all incidents will be included. | | `filters__created__at__start` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at less than this value will be omitted from the results. The maximum supported time range in conjunction with created_at_end is one year. | | `filters__min__ackowledgements` | integer | No | An integer that sets the requirement for the minimum number of acknowledgements to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 acknowledgement. If no value is provided, all incidents will be included. | | `filters__escalation__policy__ids` | array | No | An array of escalation policy IDs. Only incidents related to these escalation policies will be included in the results. If omitted, all escalation policies the requestor has access to will be included in the results. | | `filters__min__manual__escalations` | integer | No | An integer that sets the requirement for the minimum number of manual escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 manual escalation. If no value is provided, all incidents will be included. | | `filters__min__timeout__escalations` | integer | No | An integer that sets the requirement for the minimum number of timeout escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 timeout escalation. If no value is provided, all incidents will be included. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post analytics metrics responder filters **Slug:** `PAGERDUTY_POST_ANALYTICS_METRICS_RESPONDER_FILTERS` The AnalyzeResponderMetrics endpoint aggregates and analyzes responder performance metrics for PagerDuty incidents. It provides insights into response times, efficiency, and workload distribution. This tool is ideal for assessing and optimizing incident response processes, offering flexible filtering options for focused analysis. Note that it provides aggregated data, not real-time information, with a maximum analysis range of one year. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `order` | string ("asc" | "desc") | No | The order in which the results were sorted; asc for ascending, desc for descending. | | `order_by` | string | No | The column that was used for ordering the results. | | `time_zone` | string | No | The time zone to use for the results and grouping. | | `filters__urgency` | string ("high" | "low") | No | Any incidents whose urgency does not match the provided string will be omitted from the results. | | `filters__team__ids` | array | No | An array of team IDs. Only incidents related to these teams will be included in the results. If omitted, all teams the requestor has access to will be included in the results. | | `filters__priority__ids` | array | No | An array of priority IDs. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__responder__ids` | array | No | An array of responder IDs. Only incidents related to these responders will be included in the results. If omitted, all responders the requestor has access to will be included in the results. | | `filters__priority__names` | array | No | An array of user-defined priority names. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__date__range__end` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at greater than or equal to this value will be omitted from the results. The maximum supported time range in conjunction with date_range_start is one year. | | `filters__date__range__start` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at less than this value will be omitted from the results. The maximum supported time range in conjunction with date_range_end is one year. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Send change event to PagerDuty **Slug:** `PAGERDUTY_POST_CHANGE_EVENTS` Send a change event to PagerDuty to track deployments, configuration changes, or other significant system modifications. Change events do not create incidents or notifications but provide valuable context for incident correlation and analysis. Use this action to: - Log deployments and code releases - Track configuration changes - Record infrastructure updates - Document system modifications - Provide context for incident investigation Change events can be viewed in PagerDuty's change timeline and are automatically correlated with incidents to help teams understand what changed before an incident occurred. **Note:** This endpoint uses the Events API (events.pagerduty.com), not the REST API. You need an Events API v2 integration key (routing_key) from a service integration. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `links` | array | No | List of links related to the change event, such as links to build pipelines, deployment dashboards, or other relevant resources. | | `payload` | object | Yes | The payload containing details about the change event. | | `routing_key` | string | Yes | The integration key (also known as routing key) for an Events API v2 integration on a PagerDuty service. This identifies which service the change event should be associated with. You can obtain this from a service's integration configuration. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post event orchestration cache variables **Slug:** `PAGERDUTY_POST_EVENT_ORCHESTRATION_CACHE_VARIABLES` Creates a new cache variable within a PagerDuty event orchestration. This endpoint allows you to define a cache variable that can store dynamic data related to events, either based on recent values extracted from event fields or by counting trigger events within a specified time range. Cache variables are useful for maintaining state across multiple events and can be used in event routing and automation rules. The created cache variable can be configured with conditions to determine when it should be updated and can be optionally disabled. This tool should be used when setting up complex event orchestrations that require stateful processing or when implementing advanced automation workflows in PagerDuty. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. This is the unique identifier for the event orchestration where the cache variable will be created. | | `cache__variable__name` | string | Yes | The name of the cache variable. This is a required field and should be a descriptive name for the cache variable (e.g., 'recent_source', 'event_counter'). | | `cache__variable__disabled` | boolean | No | Optional boolean indicating whether the cache variable is disabled. If true, the cache variable will not be evaluated. Defaults to false (enabled). | | `cache__variable__conditions` | array | No | Optional list of PCL condition strings. Each condition is evaluated to check if an event matches this rule. The rule is considered a match if **any** of these conditions match. Each condition object should have an 'expression' field with a PCL condition string. Example: [{'expression': 'event.severity matches "critical"'}] | | `cache__variable__configuration` | object | Yes | Configuration object for the cache variable (required). Must contain 'type' field with one of: 'recent_value' (stores most recent value from an event field), 'trigger_event_count' (counts matching events over time), or 'external_data' (stores externally provided data). For 'recent_value': include 'source' (PCL path to event field) and optional 'regex' pattern. For 'trigger_event_count' or 'external_data': include 'ttl_seconds' (time to live in seconds). Example: {'type': 'recent_value', 'source': 'event.source', 'regex': '.*'} | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post incident metrics **Slug:** `PAGERDUTY_POST_INCIDENT_METRICS` Retrieve analytics metrics for responders and teams including incident counts, response times, on-call hours, interruptions, escalations, and engagement statistics. Returns metrics like total incidents, mean time to acknowledge/resolve, on-call duration by level, interruptions by time period (business/off/sleep hours), and escalation/reassignment counts. All parameters are optional (defaults to yesterday's data). Maximum date range: 1 year. Analytics data updates daily (not real-time). Use for performance reports, workload analysis, trend identification, and team comparisons. Date filters use ISO8601 format (e.g., "2026-01-01T00:00:00Z"). #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `order` | string ("asc" | "desc") | No | Sort order for results: 'asc' for ascending or 'desc' for descending. Defaults to 'asc' if omitted. | | `order_by` | string | No | Field to sort results by (e.g., 'responder_id', 'responder_name', 'total_incident_count'). Defaults to 'responder_id' if omitted. | | `time_zone` | string | No | Time zone for date grouping and time calculations (e.g., 'America/New_York', 'Europe/London', 'UTC'). Defaults to 'Etc/UTC' if omitted. | | `filters__urgency` | string ("high" | "low") | No | Filter by incident urgency. Valid values: 'high' or 'low'. Only incidents matching this urgency level are included. If omitted, includes all urgencies. | | `filters__team__ids` | array | No | List of team IDs (e.g., ['PABCDEF', 'PXYZ123']) to filter by. Only incidents assigned to these teams are included. If omitted, includes all teams the user has access to. | | `filters__priority__ids` | array | No | List of priority IDs (e.g., ['PZIQFZ2', 'PW92EJC']) to filter by. Only incidents with these priority IDs are included. Cannot be used together with priority_names. If omitted, includes all priorities. | | `filters__responder__ids` | array | No | List of user/responder IDs (e.g., ['PUVQN44', 'PXARDEH']) to filter by. Only metrics for these specific responders are included. If omitted, includes all responders the user has access to. | | `filters__priority__names` | array | No | List of priority names (e.g., ['P1', 'P2', 'Critical']) to filter by. Only incidents with these priority names are included. Cannot be used together with priority_ids. If omitted, includes all priorities. | | `filters__date__range__end` | string | No | End of date range in ISO8601 format (e.g., '2026-01-29T23:59:59Z'). Only incidents created before this time are included. If omitted, defaults to today at 00:00:00 UTC. Maximum range with date_range_start is 1 year. | | `filters__date__range__start` | string | No | Start of date range in ISO8601 format (e.g., '2026-01-01T00:00:00Z'). Only incidents created at or after this time are included. If omitted, defaults to yesterday at 00:00:00 UTC. Maximum range with date_range_end is 1 year. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post incident metrics with filters **Slug:** `PAGERDUTY_POST_INCIDENT_METRICS_WITH_FILTERS` This endpoint retrieves and aggregates analytics metrics for incidents across all teams in PagerDuty. It allows users to apply various filters and parameters to analyze incident data, such as creation date range, urgency, team associations, and more. The endpoint is particularly useful for generating reports, identifying trends, and performing operational reviews across multiple teams and services. It provides flexibility in data aggregation and sorting, enabling users to customize their analysis based on specific needs and time frames. However, users should be aware of the one-year limitation on the date range when using the created_at filters. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `order` | string ("asc" | "desc") | No | The order in which the results were sorted; asc for ascending, desc for descending. | | `order_by` | string | No | The column that was used for ordering the results. | | `time_zone` | string | No | The time zone to use for the results and grouping. Must be in tzdata format. See list of accepted values [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). | | `aggregate_unit` | string ("day" | "week" | "month") | No | The time unit to aggregate metrics by. If no value is provided, the metrics will be aggregated for the entire period. | | `filters__major` | boolean | No | A boolean flag including whether results should contain *only* [major incidents](https://support.pagerduty.com/docs/operational-reviews#major-incidents), or exclude major incidents. If no value is provided all incidents will be included. | | `filters__urgency` | string ("high" | "low") | No | Any incidents whose urgency does not match the provided string will be omitted from the results. | | `filters__team__ids` | array | No | An array of team IDs. Only incidents related to these teams will be included in the results. If omitted, all teams the requestor has access to will be included in the results. | | `filters__service__ids` | array | No | An array of service IDs. Only incidents related to these services will be included in the results. If omitted, all services the requestor has access to will be included in the results. | | `filters__priority__ids` | array | No | An array of priority IDs. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__priority__names` | array | No | An array of user-defined priority names. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__created__at__end` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at greater than or equal to this value will be omitted from the results. The maximum supported time range in conjunction with created_at_start is one year. | | `filters__pd__advance__used` | boolean | No | If true, only incidents where PD Advance was used will be included in the results, and vice versa. If omitted, all incidents will be included. | | `filters__created__at__start` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at less than this value will be omitted from the results. The maximum supported time range in conjunction with created_at_end is one year. | | `filters__min__ackowledgements` | integer | No | An integer that sets the requirement for the minimum number of acknowledgements to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 acknowledgement. If no value is provided, all incidents will be included. | | `filters__escalation__policy__ids` | array | No | An array of escalation policy IDs. Only incidents related to these escalation policies will be included in the results. If omitted, all escalation policies the requestor has access to will be included in the results. | | `filters__min__manual__escalations` | integer | No | An integer that sets the requirement for the minimum number of manual escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 manual escalation. If no value is provided, all incidents will be included. | | `filters__min__timeout__escalations` | integer | No | An integer that sets the requirement for the minimum number of timeout escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 timeout escalation. If no value is provided, all incidents will be included. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post incident note using id **Slug:** `PAGERDUTY_POST_INCIDENT_NOTE_USING_ID` Adds a new note to an existing incident in PagerDuty. This endpoint allows users to append additional information, updates, or comments to a specific incident identified by its unique ID. It's particularly useful for documenting the progress of incident resolution, sharing important observations, or recording actions taken. The note content can include any text relevant to the incident management process, helping teams collaborate and maintain a clear record of the incident's timeline and handling. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The incident ID to add the note to. You can obtain incident IDs from the list incidents action. | | `note__content` | string | Yes | The text content of the note to add to the incident. This can include investigation details, status updates, resolution steps, or any other relevant information about the incident. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post incidents analytics with filters **Slug:** `PAGERDUTY_POST_INCIDENTS_ANALYTICS_WITH_FILTERS` The AnalyzeRawIncidents endpoint retrieves and analyzes raw incident data from PagerDuty. It allows users to fetch detailed information about incidents with various filtering options. This endpoint is useful for generating custom reports, performing trend analysis, or investigating specific incident sets. It supports extensive filtering, pagination, and result customization, making it ideal for in-depth incident reviews and pattern analysis. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | Number of results to include in each batch. Limits between 1 to 1000 are accepted. | | `order` | string ("asc" | "desc") | No | The order the results; asc for ascending, desc for descending. Defaults to "desc". | | `order_by` | string ("created_at" | "seconds_to_resolve") | No | The column to use for ordering the results. Defaults to "created_at". | | `time_zone` | string | No | The time zone to use for the results. | | `ending_before` | string | No | A cursor to indicate the reference point that the results should precede | | `filters__major` | boolean | No | An incident is classified as a [major incident](https://support.pagerduty.com/docs/operational-reviews#major-incidents) if it has one of the two highest priorities, or if multiple responders are added and acknowledge the incident. | | `starting_after` | string | No | A cursor to indicate the reference point that the results should follow | | `filters__urgency` | string | No | Filters the result, showing only the incidents where urgency matches the filter value. | | `filters__team__ids` | array | No | An array of team IDs. Only incidents that are assigned to a member of these teams will be returned. Account must have the teams ability to use this parameter. | | `filters__service__ids` | array | No | An array of service IDs. Only results related to these services will be returned. | | `filters__priority__ids` | array | No | The priority_ids filter applied to the results. | | `filters__updated__after` | string | No | Filters the result, showing only incidents where the updated_at value is greater than the filter value. | | `filters__priority__names` | array | No | The priority_names filter applied to the results. | | `filters__created__at__end` | string | No | Filters the result, showing only the incidents where the creation timestamp is less than the filter value. | | `filters__created__at__start` | string | No | Filters the result, showing only the incidents where the creation timestamp is greater than or equal to the filter value. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post incidents metrics filtered by service **Slug:** `PAGERDUTY_POST_INCIDENTS_METRICS_FILTERED_BY_SERVICE` The AnalyzeIncidentMetrics endpoint aggregates and analyzes incident data for PagerDuty services based on specified filters and parameters. It allows users to generate detailed reports and insights on incident management performance across various dimensions such as time, urgency, teams, and services. This endpoint is particularly useful for operational reviews, trend analysis, and performance monitoring of incident response processes. The tool provides flexible filtering options to focus on specific subsets of incidents and supports various time-based aggregations for comprehensive analysis. It's important to note that while the endpoint offers extensive customization, it has a maximum supported time range of one year between the start and end dates for incident creation. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `order` | string ("asc" | "desc") | No | The order in which the results were sorted; asc for ascending, desc for descending. | | `order_by` | string | No | The column that was used for ordering the results. | | `time_zone` | string | No | The time zone to use for the results and grouping. Must be in tzdata format. See list of accepted values [here](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). | | `aggregate_unit` | string ("day" | "week" | "month") | No | The time unit to aggregate metrics by. If no value is provided, the metrics will be aggregated for the entire period. | | `filters__major` | boolean | No | A boolean flag including whether results should contain *only* [major incidents](https://support.pagerduty.com/docs/operational-reviews#major-incidents), or exclude major incidents. If no value is provided all incidents will be included. | | `filters__urgency` | string ("high" | "low") | No | Any incidents whose urgency does not match the provided string will be omitted from the results. | | `filters__team__ids` | array | No | An array of team IDs. Only incidents related to these teams will be included in the results. If omitted, all teams the requestor has access to will be included in the results. | | `filters__service__ids` | array | No | An array of service IDs. Only incidents related to these services will be included in the results. If omitted, all services the requestor has access to will be included in the results. | | `filters__priority__ids` | array | No | An array of priority IDs. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__priority__names` | array | No | An array of user-defined priority names. Only incidents with these priorities will be included in the results. If omitted, all priorities will be included in the results. | | `filters__created__at__end` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at greater than or equal to this value will be omitted from the results. The maximum supported time range in conjunction with created_at_start is one year. | | `filters__pd__advance__used` | boolean | No | If true, only incidents where PD Advance was used will be included in the results, and vice versa. If omitted, all incidents will be included. | | `filters__created__at__start` | string | No | Accepts an ISO8601 DateTime string. Any incidents with a created_at less than this value will be omitted from the results. The maximum supported time range in conjunction with created_at_end is one year. | | `filters__min__ackowledgements` | integer | No | An integer that sets the requirement for the minimum number of acknowledgements to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 acknowledgement. If no value is provided, all incidents will be included. | | `filters__escalation__policy__ids` | array | No | An array of escalation policy IDs. Only incidents related to these escalation policies will be included in the results. If omitted, all escalation policies the requestor has access to will be included in the results. | | `filters__min__manual__escalations` | integer | No | An integer that sets the requirement for the minimum number of manual escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 manual escalation. If no value is provided, all incidents will be included. | | `filters__min__timeout__escalations` | integer | No | An integer that sets the requirement for the minimum number of timeout escalations to occur on an incident. For example, setting this to 1 will return only incidents that have at least 1 timeout escalation. If no value is provided, all incidents will be included. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post incident status update **Slug:** `PAGERDUTY_POST_INCIDENT_STATUS_UPDATE` Posts a status update for a specific incident in PagerDuty. This endpoint allows you to add new information or progress reports to an ongoing incident, keeping stakeholders informed about the current state of the issue. It supports both simple text updates and more detailed custom HTML email updates. Use this when you need to communicate important changes, actions taken, or any relevant information about the incident to the team or stakeholders. The endpoint is particularly useful for maintaining a clear timeline of the incident's progression and ensuring all parties have the most up-to-date information. Note that while a simple message is always required, you have the option to provide additional details through a custom HTML email by including both the 'subject' and 'html_message' fields. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident to post a status update to. You can obtain incident IDs from the list incidents action. | | `message` | string | Yes | The message to be posted as a status update. | | `subject` | string | No | The subject to be sent for the custom html email status update. Required if sending custom html email. | | `html_message` | string | No | The html content to be sent for the custom html email status update. Required if sending custom html email. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post responder incidents with filters **Slug:** `PAGERDUTY_POST_RESPONDER_INCIDENTS_WITH_FILTERS` Retrieves a list of incidents associated with a specific responder in the PagerDuty incident management system. This endpoint allows for detailed filtering and pagination of incident data, making it ideal for analyzing a responder's workload, performance, and incident trends over time. It supports various filter criteria such as creation time range, urgency, major incident status, team and service associations, and priority levels. The tool is particularly useful for generating reports, conducting operational reviews, and optimizing incident response processes. It should be used when detailed incident information for a specific responder is needed, but not for real-time incident updates or for modifying incident data. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | Number of results to include in each batch. Limits between 1 to 1000 are accepted. | | `order` | string ("asc" | "desc") | No | The order in which to display the results; asc for ascending, desc for descending. Defaults to `desc`. | | `order_by` | string ("incident_created_at") | No | The column to use for ordering the results. Defaults to `incident_created_at`. | | `time_zone` | string | No | The time zone to use for the results. | | `responder_id` | string | Yes | The ID of the responder. | | `ending_before` | string | No | A cursor to indicate the reference point that the results should precede | | `filters__major` | boolean | No | An incident is classified as a [major incident](https://support.pagerduty.com/docs/operational-reviews#major-incidents) if it has one of the two highest priorities, or if multiple responders are added and acknowledge the incident. | | `starting_after` | string | No | A cursor to indicate the reference point that the results should follow | | `filters__urgency` | string | No | Filters the result, showing only the incidents where urgency matches the filter value. | | `filters__team__ids` | array | No | An array of team IDs. Only incidents that are assigned to a member of these teams will be returned. Account must have the teams ability to use this parameter. | | `filters__service__ids` | array | No | An array of service IDs. Only results related to these services will be returned. | | `filters__priority__ids` | array | No | The priority_ids filter applied to the results. | | `filters__priority__names` | array | No | The priority_names filter applied to the results. | | `filters__created__at__end` | string | No | Filters the result, showing only the incidents where the creation timestamp is less than the filter value. | | `filters__created__at__start` | string | No | Filters the result, showing only the incidents where the creation timestamp is greater than the filter value. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post service automation action **Slug:** `PAGERDUTY_POST_SERVICE_AUTOMATION_ACTION` This endpoint adds a service to an existing automation action in PagerDuty. It allows users to associate a specific service with an automation action, enabling the action to be applied to incidents or events related to that service. The endpoint requires the automation action's ID in the URL path and a service reference object in the request body. It should be used when configuring or updating automation actions to include additional services in their scope of operation. This endpoint is particularly useful for expanding the reach of automation actions across multiple services within an organization's PagerDuty setup. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the automation action to associate the service with. | | `service` | object | Yes | The service reference object containing the service ID to associate. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post team notification subscription **Slug:** `PAGERDUTY_POST_TEAM_NOTIFICATION_SUBSCRIPTION` Creates notification subscriptions for a specific team in PagerDuty. This endpoint allows you to subscribe a team to receive notifications for one or more incidents or business services. Use this when you want to ensure a team is notified about specific critical events or the status of important business services. The endpoint requires a list of subscribable entities, each identified by a unique ID and type. It's particularly useful for setting up or updating a team's notification preferences in bulk. Note that this endpoint only creates new subscriptions and doesn't affect existing ones. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the team to create notification subscriptions for. This is a PagerDuty team ID (e.g., 'P123ABC'). | | `subscribables` | array | Yes | List of entities (incidents or business services) that the team should be subscribed to for notifications. Each item specifies a subscribable_id and subscribable_type. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Post team to runner **Slug:** `PAGERDUTY_POST_TEAM_TO_RUNNER` This endpoint adds a team to an Automation Action Runner in PagerDuty. It allows you to associate a specific team with a runner, enabling better organization and management of automation processes within your incident response workflow. Use this endpoint when you need to grant a team access to or responsibility for a particular Automation Action Runner. This association is crucial for maintaining proper access control and ensuring that the right teams are involved in specific automation tasks. The endpoint requires the runner's ID and the team's reference information, including its unique identifier and type. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the runner to associate the team with. | | `team` | object | Yes | The team reference object containing the team ID to associate. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Preview schedule object **Slug:** `PAGERDUTY_PREVIEW_SCHEDULE_OBJECT` The preview_schedule endpoint allows you to simulate and visualize a PagerDuty schedule configuration before actually creating or updating it. This tool is essential for validating complex on-call rotations, ensuring proper coverage, and identifying potential gaps or conflicts in your schedule design. It accepts a complete schedule object, including multiple layers, users, and restrictions, and returns a preview of how the schedule would operate if implemented. This preview includes rendered schedule entries, showing exactly who would be on-call at specific times. Use this endpoint when designing new schedules, modifying existing ones, or troubleshooting scheduling issues to ensure optimal on-call coverage without affecting your live environment. The preview does not create or modify any actual schedules in your PagerDuty account. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `since` | string | No | The start of the date range over which you want to search. If not provided, defaults to current time. | | `until` | string | No | The end of the date range over which you want to search. If not provided, defaults to 2 weeks after 'since'. | | `overflow` | boolean | No | Any on-call schedule entries that pass the date range bounds will be truncated at the bounds, unless the parameter `overflow=true` is passed. This parameter defaults to false. For instance, if your schedule is a rotation that changes daily at midnight UTC, and your date range is from `2011-06-01T10:00:00Z` to `2011-06-01T14:00:00Z`: - If you don"t pass the `overflow=true` parameter, you will get one schedule entry returned with a start of `2011-06-01T10:00:00Z` and end of `2011-06-01T14:00:00Z`. - If you do pass the `overflow=true` parameter, you will get one schedule entry returned with a start of `2011-06-01T00:00:00Z` and end of `2011-06-02T00:00:00Z`. | | `schedule` | object | Yes | The schedule object to preview with layers, users, and time configuration | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Render template for incident **Slug:** `PAGERDUTY_RENDER_TEMPLATE_FOR_INCIDENT` Renders a specific template for a given incident in PagerDuty. This endpoint allows you to generate a formatted report or message based on a pre-defined template and the provided incident information. It's particularly useful for creating standardized incident reports, status updates, or notifications. The rendered template can incorporate details from the incident, a status update message, and any additional external data provided. Use this endpoint when you need to generate consistent, formatted output for incident communication or documentation purposes. Note that the template itself must be created and configured separately; this endpoint only handles the rendering process based on the template identified by the URL parameter {id}. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the template to render. | | `external` | object | No | Optional external data to be used in template rendering. | | `incident_id` | string | Yes | The ID of the incident to render the template for. | | `status_update__message` | string | No | Optional status update message to include in the template rendering. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve abilities list **Slug:** `PAGERDUTY_RETRIEVE_ABILITIES_LIST` Retrieves a list of abilities or capabilities available in the PagerDuty system. This endpoint allows users to query and understand the features and functionalities they can access or perform within PagerDuty. It's particularly useful for determining the scope of actions available to the authenticated user or for checking the overall feature set of the PagerDuty instance. The endpoint should be used when you need to discover or verify the available abilities, such as during initial setup, permission audits, or when planning integrations. It does not modify any data and is safe to call frequently. #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Test ability availability by ID **Slug:** `PAGERDUTY_RETRIEVE_ABILITY_BY_ID` Tests whether a specific ability (feature capability) is available to your PagerDuty account using its unique identifier. This endpoint checks if a particular feature, such as 'urgencies', 'manage_schedules', or 'event_rules', is available based on your account's pricing plan and configuration. A successful response (HTTP 204) indicates the ability exists and is available; a 404 error indicates the ability is not available or doesn't exist. This is useful for programmatically checking feature availability before attempting to use specific functionality. Use the list abilities endpoint to discover available ability IDs. The endpoint is read-only and does not modify any abilities. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve action services by id **Slug:** `PAGERDUTY_RETRIEVE_ACTION_SERVICES_BY_ID` Retrieves a list of services associated with a specific automation action in PagerDuty. This endpoint allows users to fetch all services that are linked to a particular automation action, providing insights into which components or systems are affected by the automated process. It's useful for auditing automation configurations, understanding the scope of automated actions, and managing incident response workflows. The endpoint should be used when you need to review or verify the services connected to an automation action, but it won't provide details about the action itself or modify any existing configurations. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the automation action. This is the unique identifier for the automation action whose associated services you want to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Check if service event orchestration is active **Slug:** `PAGERDUTY_RETRIEVE_ACTIVE_SERVICE_EVENT_BY_ID` Check if event orchestration is active for a specific PagerDuty service. This endpoint returns a boolean flag indicating whether Service Event Orchestration is currently active for the specified service. When active, events sent to this service are processed through the service's event orchestration rules before creating incidents. Use this to quickly determine if a service has event orchestration enabled or disabled. This is useful for validating service configuration or troubleshooting event processing behavior. Note: This endpoint only returns the active status (true/false), not the actual orchestration rules or configuration. To view or modify the orchestration rules, use the service orchestration endpoints instead. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `service_id` | string | Yes | The ID of the PagerDuty service to check event orchestration status for | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve addon by id **Slug:** `PAGERDUTY_RETRIEVE_ADDON_BY_ID` Retrieves detailed information about a specific addon installed on a PagerDuty account. This endpoint allows users to fetch the current configuration, status, and other relevant details of an addon without modifying it. It's particularly useful for auditing installed addons, troubleshooting integration issues, or gathering information before making changes to an addon's setup. The endpoint returns a comprehensive view of the addon, which may include its type, version, configuration parameters, and current operational status. Use this endpoint when you need to inspect or verify the details of a particular addon in your PagerDuty environment. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the addon to retrieve. This is a unique identifier for a specific addon installed on your PagerDuty account. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve alert grouping settings by id **Slug:** `PAGERDUTY_RETRIEVE_ALERT_GROUPING_SETTINGS_BY_ID` Retrieves the alert grouping settings for a specific configuration identified by its unique ID in PagerDuty. This endpoint allows users to access detailed information about how alerts are grouped for a particular service or team. It's useful for reviewing current grouping rules, understanding the logic behind incident correlation, and auditing alert management configurations. The endpoint should be used when you need to examine or verify the existing alert grouping settings, which can be crucial for optimizing incident response and reducing alert fatigue. It does not modify any settings and is intended for read-only operations. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve automation action invocation by id **Slug:** `PAGERDUTY_RETRIEVE_AUTOMATION_ACTION_INVOCATION_BY_ID` Retrieves detailed information about a specific automation action invocation in PagerDuty. This endpoint allows you to fetch the current state, results, and metadata of a previously executed automation action. It's particularly useful for tracking the progress of long-running automations, auditing past actions, or troubleshooting failed invocations. The endpoint should be used when you need to review the outcome of a specific automation run or gather data for reporting purposes. Note that this endpoint only provides information about the invocation itself and does not allow modification of the automation action or re-running of the invocation. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the automation action invocation to retrieve. This is the ID returned when an automation action is invoked or from listing invocations. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve automation action invocations **Slug:** `PAGERDUTY_RETRIEVE_AUTOMATION_ACTION_INVOCATIONS` Retrieves a list of automation action invocations from the PagerDuty incident management platform. This endpoint allows users to query and review the history of automated actions that have been executed within their PagerDuty environment. It can be used to audit automation processes, track the frequency and timing of automated responses, and analyze the effectiveness of incident management workflows. The endpoint is particularly useful for administrators and DevOps teams who need to monitor and optimize their automated incident response strategies. Note that while this endpoint provides historical data, it does not trigger new automated actions or modify existing ones. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `action_id` | string | No | Filter invocations for a specific automation action. Provide the action ID to see all times this particular automation action has been invoked across incidents. | | `incident_id` | string | No | Filter invocations associated with a specific PagerDuty incident. Provide the incident ID (e.g., 'PABC123') to view all automation actions invoked for that incident. | | `invocation_state` | string ("prepared" | "created" | "sent" | "queued" | "running" | "aborted" | "completed" | "error" | "unknown") | No | Filter invocations by their current state. Use this to find invocations in a specific state like 'completed', 'running', 'error', etc. Only invocations matching this state will be returned. | | `not_invocation_state` | string ("prepared" | "created" | "sent" | "queued" | "running" | "aborted" | "completed" | "error" | "unknown") | No | Filter invocations by excluding a specific state. Returns all invocations EXCEPT those in the specified state. For example, use 'completed' to find all invocations that are still pending or in progress. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve automation action runner teams **Slug:** `PAGERDUTY_RETRIEVE_AUTOMATION_ACTION_RUNNER_TEAMS` Retrieves detailed information about a specific team association with an Automation Actions runner in PagerDuty. This endpoint confirms whether a particular team has access to a given runner and returns the team's details. Use this action when you need to: - Verify that a specific team is associated with a runner - Get team details (ID, name summary, URLs) for a known team-runner pair - Confirm access permissions before performing automation actions - Audit team-runner relationships for security or compliance purposes The endpoint returns a team object containing: id, type, summary, self (API URL), and html_url. This is a read-only operation that does not modify any associations. Note: To get all teams associated with a runner, use the 'fetch_runner_teams_integration' action instead. To create a new team-runner association, use 'post_team_to_runner'. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the Automation Action Runner (e.g., 'P1RUNNER', 'PRUNNER123'). This ID is returned when creating a runner or can be obtained by listing all runners. | | `team_id` | string | Yes | The unique identifier of the team associated with the runner (e.g., 'P1TEAM01', 'PTEAM123'). Team IDs can be obtained by listing teams or from team creation responses. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve automation service action **Slug:** `PAGERDUTY_RETRIEVE_AUTOMATION_SERVICE_ACTION` Retrieves detailed information about the association between a specific automation action and a service in PagerDuty. This endpoint returns both the automation action details (including ID, name, type, and configuration) and the service details (including ID, name, type, and status) for the specified association. Use this endpoint when you need to: - Verify that an automation action is correctly associated with a service - Retrieve configuration details for an existing action-service association - Audit which automation actions are linked to specific services - Understand the automation setup for incident management on a particular service Note: This endpoint requires both an automation action ID and a service ID. The association must already exist - use the associate endpoint to create new associations. Automation Actions is a premium feature and requires appropriate account permissions. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the automation action. | | `service_id` | string | Yes | The ID of the service that is associated with the automation action. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve business service by id **Slug:** `PAGERDUTY_RETRIEVE_BUSINESS_SERVICE_BY_ID` Retrieves detailed information about a specific business service by its ID. Returns the business service's name, description, point of contact, associated team, and other metadata. Use this when you need to view or verify the details of a single business service. Note: This endpoint returns configuration data only - it does not include real-time incident data, performance metrics, or service dependencies. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique ID of the business service to retrieve (e.g., 'PEWAEZ5', 'P5GGAQM'). You can obtain business service IDs by listing business services first. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve business service dependencies **Slug:** `PAGERDUTY_RETRIEVE_BUSINESS_SERVICE_DEPENDENCIES` Retrieves the service dependencies for a specific business service in PagerDuty. This endpoint allows you to fetch a list of services that are dependent on or related to the specified business service, helping to understand the interconnections within your incident management structure. Use this when you need to analyze the impact of incidents on critical business functions or when planning incident response strategies. The endpoint provides a snapshot of the current dependency structure and does not include historical data or future planned changes to service relationships. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the business service to retrieve dependencies for. This should be a valid business service ID from PagerDuty (e.g., 'PEWAEZ5'). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve business service impactors **Slug:** `PAGERDUTY_RETRIEVE_BUSINESS_SERVICE_IMPACTORS` Retrieves impactors (typically incidents) currently affecting business services. Use this to monitor which incidents are impacting services, identify cascading failures, and prioritize incident response based on business impact. **Parameters:** - ids (optional): Filter by specific business service IDs. Accepts a single ID (string) or multiple IDs (list). Omit to get impactors for all services. **Returns:** List of impactors with IDs and types, plus pagination info. Currently limited to active incidents only - no historical data. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `ids` | string | No | Optional. Business service IDs to filter impactors. Can be a single ID (string) or multiple IDs (list of strings). Examples: 'PABC123' or ['PABC123', 'PXYZ789']. If omitted, returns impactors for all business services. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve business service impacts **Slug:** `PAGERDUTY_RETRIEVE_BUSINESS_SERVICE_IMPACTS` Retrieves a list of business services impacted by a specific PagerDuty incident. This helps assess the broader business impact and identify which business stakeholders need to be notified during incident response. Use this action to: - Understand which business services are affected by an incident - Prioritize incident response based on critical business service impacts - Identify stakeholders who need to be notified - Generate impact reports for incident post-mortems Returns a list of impacted business services with their details (ID, name, links), or an empty array if the incident doesn't impact any business services. Business services must be configured in PagerDuty with qualifying incident priority levels to appear in results. Works with both triggered and resolved incidents. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the PagerDuty incident for which you want to retrieve business service impacts. This should be a valid incident ID in the format of a PagerDuty resource identifier (e.g., 'Q1LM34T0WT52EL'). You can obtain incident IDs from the fetch incident list action or incident webhook events. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve business services **Slug:** `PAGERDUTY_RETRIEVE_BUSINESS_SERVICES` Retrieve a list of business services from your PagerDuty account. Business services represent the high-level business capabilities that your technical services support. They provide a business-oriented view of your infrastructure, helping you understand which business functions are affected during incidents. This endpoint supports pagination through the limit and offset parameters, allowing you to efficiently retrieve large lists of business services. Use the total parameter to get the exact count of business services (note: this may impact response time). Common use cases: - Getting an overview of all business services in your organization - Building dashboards that show business service status - Auditing and reporting on business service configurations - Integrating business service data with external systems #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results to return per page. Default is 25, maximum is 100. | | `total` | boolean | No | If true, the response will include the total count of business services. By default this is false/null for faster response times. Set to true when you need to know the exact total count for pagination purposes. | | `offset` | integer | No | The offset for pagination. Use this to retrieve subsequent pages of results. Default is 0. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve change event by id **Slug:** `PAGERDUTY_RETRIEVE_CHANGE_EVENT_BY_ID` Retrieves detailed information about a specific change event by its unique ID. Change events represent deployments, configuration changes, infrastructure updates, or other system modifications that are tracked for incident correlation and analysis. Unlike incidents or alerts, change events are informational and do not trigger notifications. **Use Cases:** - View details of a specific deployment or change - Investigate changes that occurred before an incident - Audit change management processes - Track the timeline and impact of system modifications **Requirements:** - Requires the PagerDuty AIOps add-on - Requires `change_events.read` scope/permission **Note:** Change events are created via the Events API v2 `/v2/change/enqueue` endpoint or automatically from integrated tools like CI/CD pipelines. This endpoint retrieves the details of an already-created change event. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the change event to retrieve. This is the change event ID returned when listing change events or creating a change event. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve change event information **Slug:** `PAGERDUTY_RETRIEVE_CHANGE_EVENT_INFORMATION` Retrieves change events from PagerDuty. Change events track deployments, configuration changes, and infrastructure updates in your external systems. They provide context for incident correlation by showing what changed before an incident occurred. Use this to review deployments, track infrastructure changes, correlate changes with incidents, or investigate what changed before problems started. Change events appear in PagerDuty's timeline and are automatically correlated with incidents. Filter by team_ids, integration_ids, or time range (since/until). Use limit/offset for pagination. Note: Requires PagerDuty AIOps add-on. Events older than 90 days are not shown. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `since` | string | No | The start of the date range over which you want to search, as a UTC ISO 8601 datetime string. Will return an HTTP 400 for non-UTC datetimes. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `until` | string | No | The end of the date range over which you want to search, as a UTC ISO 8601 datetime string. Will return an HTTP 400 for non-UTC datetimes. | | `offset` | integer | No | Offset to start pagination search results. | | `team__ids` | array | No | An array of team IDs. Only results related to these teams will be returned. Account must have the `teams` ability to use this parameter. | | `integration__ids` | array | No | An array of integration IDs. Only results related to these integrations will be returned. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve current user info **Slug:** `PAGERDUTY_RETRIEVE_CURRENT_USER_INFO` Retrieves the profile information of the currently authenticated user in the PagerDuty system. This endpoint provides access to personal details, settings, and account information associated with the user making the API request. It's particularly useful for applications that need to display or utilize user-specific data without requiring additional input. The endpoint should be used when an application needs to fetch up-to-date information about the current user, such as their name, email, role, or other account-related details. Note that this endpoint does not provide information about other users in the organization, nor does it allow for modifications to the user profile. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `include` | array | No | Array of additional Models to include in response. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve entity tags by id **Slug:** `PAGERDUTY_RETRIEVE_ENTITY_TAGS_BY_ID` Retrieves the tags associated with a specific entity in the PagerDuty system. This endpoint allows you to fetch all tags that have been assigned to a particular resource. Supported entity types are users, teams, and escalation_policies. Tags are useful for categorization, filtering, and organizing entities within PagerDuty. The endpoint requires specifying both the entity type and its unique identifier to correctly locate the resource. This operation is read-only and does not modify any data. Supports pagination via limit and offset parameters. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique ID of the entity (user ID, team ID, or escalation policy ID). | | `limit` | integer | No | The number of results per page. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | | `entity_type` | string ("users" | "teams" | "escalation_policies") | Yes | Type of entity to retrieve tags for. Supported types: users, teams, or escalation_policies. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve event orchestration router by id **Slug:** `PAGERDUTY_RETRIEVE_EVENT_ORCHESTRATION_ROUTER_BY_ID` Retrieves the router configuration for a specific event orchestration in PagerDuty. This endpoint allows you to fetch detailed information about how incidents and events are routed within a particular event orchestration setup. Use this endpoint when you need to understand or audit the current routing logic for an event orchestration, such as determining which teams or escalation policies are assigned to handle specific types of incidents. The returned data will include routing rules, conditions, and associated actions, but will not modify any existing configurations. This endpoint is particularly useful for incident response planning and optimization of event management workflows. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve extension by id **Slug:** `PAGERDUTY_RETRIEVE_EXTENSION_BY_ID` Retrieves detailed information about a specific extension in PagerDuty. This endpoint allows users to fetch the configuration and status of an individual extension by providing its unique identifier. It is particularly useful when you need to review or verify the settings of a specific extension, such as its type, configuration parameters, or associated service. This endpoint should be used when detailed information about a known extension is required, but it cannot be used to list all extensions or modify extension settings. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the extension to retrieve. | | `include` | string ("extension_schemas" | "extension_objects" | "temporarily_disabled") | No | Additional details to include in the response. Options: 'extension_schemas' (full schema details), 'extension_objects' (full service/object details), or 'temporarily_disabled' (include temporarily_disabled status flag). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve extension list **Slug:** `PAGERDUTY_RETRIEVE_EXTENSION_LIST` Retrieves a paginated list of extensions associated with the authenticated PagerDuty account. Extensions are integrations that enhance PagerDuty's functionality, such as webhooks, custom notification methods, or third-party service connections. This endpoint supports filtering by extension name (query parameter), extension schema ID (vendor type), and extension object ID (the resource the extension is attached to, such as a service). Use this to audit active extensions, discover webhooks configured for specific services, or find all extensions of a particular type. The include parameter can request additional details like extension_objects or extension_schemas to be embedded in the response for richer context without additional API calls. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `query` | string | No | Search query to filter extensions by name. Returns extensions whose name contains this string (case-insensitive partial match). Example: 'webhook' or 'slack'. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | | `include` | string ("extension_objects" | "extension_schemas") | No | Additional details to embed in the response. Options: 'extension_objects' includes full details of associated resources (e.g., services), 'extension_schemas' includes complete schema information. By default, only references are returned. | | `extension_object_id` | string | No | Filter extensions by the ID of the object they're attached to. Typically a service ID (e.g., 'PXXXXXX'). Use this to find all extensions configured for a specific service or other PagerDuty resource. | | `extension_schema_id` | string | No | Filter extensions by the extension schema ID (vendor/type identifier). For example, 'PJFWPEP' for Generic V2 Webhook. Use list_extension_schemas action to discover available schema IDs. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve incident by incident id **Slug:** `PAGERDUTY_RETRIEVE_INCIDENT_BY_INCIDENT_ID` Retrieves detailed information about a specific incident in PagerDuty using its unique identifier. This endpoint allows users to access comprehensive data about an individual incident, including its current status, assigned responders, and related metadata. It is particularly useful for tracking the progress of an ongoing incident, reviewing historical incident data, or integrating incident details into external systems or reports. The endpoint should be used when specific incident information is needed, rather than for retrieving bulk or summarized incident data. Note that this endpoint provides a snapshot of the incident at the time of the request and may not reflect real-time updates without subsequent API calls. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `include` | string ("acknowledgers" | "agents" | "assignees" | "conference_bridge" | "custom_fields" | "escalation_policies" | "first_trigger_log_entries" | "priorities" | "services" | "teams" | "users") | No | Array of additional details to include. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve incident custom fields **Slug:** `PAGERDUTY_RETRIEVE_INCIDENT_CUSTOM_FIELDS` Retrieves a list of custom fields associated with incidents in PagerDuty. Custom fields are additional data points that can be added to incidents to provide more detailed information tailored to specific organizational needs. This endpoint allows you to fetch all defined custom fields, which can be useful for understanding the structure of incident data, preparing for incident creation or updates, or auditing the current custom field configuration. The response will include details such as field names, types, and any predefined options for each custom field. Use this endpoint when you need to review or work with the custom field definitions in your PagerDuty account, such as when integrating with other systems or preparing reports that involve custom incident data. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `include` | string ("field_options") | No | Array of additional details to include. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve incident custom field values **Slug:** `PAGERDUTY_RETRIEVE_INCIDENT_CUSTOM_FIELD_VALUES` Retrieves the custom field values associated with a specific incident in PagerDuty. This endpoint allows users to access additional metadata that has been added to an incident, providing more context and enabling better incident management. It should be used when detailed information about an incident's custom fields is needed, such as for reporting, analysis, or integration with other systems. The endpoint returns only the custom field values and does not modify the incident or its fields. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The incident ID for which to retrieve custom field values. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve incident field options **Slug:** `PAGERDUTY_RETRIEVE_INCIDENT_FIELD_OPTIONS` Retrieves the available field options for a specific custom incident field in PagerDuty. This action returns the predefined set of values that can be assigned to a multi-value or dropdown custom field. Field options are useful for: - Populating dropdown menus in incident forms - Validating user input against allowed values - Understanding possible values for categorizing incidents - Maintaining consistency in incident metadata **Prerequisites:** 1. A valid custom incident field ID (use PAGERDUTY_RETRIEVE_INCIDENT_CUSTOM_FIELDS) 2. The field should be of type 'multi_value' or 'multi_value_fixed' to have options **Note:** This endpoint requires the `incident_custom_fields:read` OAuth scope. Only fields with predefined options will return results; free-text fields have no options. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field_id` | string | Yes | The ID of the custom incident field. Use PAGERDUTY_RETRIEVE_INCIDENT_CUSTOM_FIELDS to find valid field IDs. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve incident workflow by id **Slug:** `PAGERDUTY_RETRIEVE_INCIDENT_WORKFLOW_BY_ID` Retrieves detailed information about a specific incident workflow in PagerDuty. This endpoint allows users to fetch the configuration, steps, and other relevant details of an incident workflow based on its unique identifier. It is particularly useful when you need to review or audit the structure of an existing workflow, or when you want to display the workflow details in a user interface. The endpoint returns comprehensive information about the workflow, which may include its name, description, steps, triggers, and associated incident types. It should be used when specific information about a known incident workflow is required, rather than for listing or searching workflows. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the incident workflow to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve incident workflow triggers **Slug:** `PAGERDUTY_RETRIEVE_INCIDENT_WORKFLOW_TRIGGERS` Retrieves a list of triggers associated with incident workflows in PagerDuty. This endpoint allows you to fetch information about the conditions or events that initiate automated incident response processes. Use this endpoint when you need to review, audit, or manage the triggers configured for your incident workflows. It provides valuable insights into what events can start an incident workflow, helping in the optimization of incident management strategies. The endpoint returns details about each trigger, which may include its configuration, associated workflow, and activation criteria. Note that this endpoint only provides information about existing triggers and does not allow for the creation or modification of triggers. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The minimum of the `limit` parameter used in the request or the maximum request size of the API. | | `cursor` | string | No | Optional parameter used to request the "next" set of results from an API. The value provided here is most commonly obtained from the `next_cursor` field of the previous request. When no value is provided, the request starts at the beginning of the result set. | | `sort_by` | string ("workflow_id" | "workflow_id asc" | "workflow_id desc" | "workflow_name" | "workflow_name asc" | "workflow_name desc") | No | If provided, returns triggers sorted by the specified property. | | `service_id` | string | No | If provided, only show triggers configured for incidents in the given service. Useful for listing all workflows associated with the given service. Cannot be specified if `incident_id` is provided. | | `incident_id` | string | No | If provided, only show triggers configured on the service of the given incident. Useful for finding manual triggers that are configured on the service for a specific incident. Cannot be specified if `service_id` is provided. | | `is_disabled` | boolean | No | If provided, filters between disabled and enabled Triggers. This query parameter is deprecated, and will be removed in a future version of this API. | | `workflow_id` | string | No | If provided, only show triggers configured to start the given workflow. Useful for listing all services associated with the given workflow | | `trigger_type` | string ("manual" | "conditional") | No | If provided, only show triggers of the given type. For example “manual” to search for manual triggers | | `workflow_name_contains` | string | No | If provided, only show triggers configured to start workflows whose name contain the provided value. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve integration by service id **Slug:** `PAGERDUTY_RETRIEVE_INTEGRATION_BY_SERVICE_ID` Retrieves detailed information about a specific integration associated with a particular service in PagerDuty. This endpoint allows you to fetch the configuration and status of an integration, which can be crucial for understanding how external systems or tools are connected to your PagerDuty service. Use this when you need to review or troubleshoot a specific integration's settings within the context of a service. It's particularly useful for auditing your integrations or preparing for updates to your incident management workflow. Note that this endpoint only provides read access to integration details and cannot be used to modify the integration. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the service to retrieve the integration from. | | `include` | string ("services" | "vendors") | No | Optional parameter to include additional details in the response. Use 'services' to include full service details (name, description, escalation policy, etc.), or 'vendors' to include expanded vendor information (description, logo, documentation URLs, etc.). | | `integration_id` | string | Yes | The unique ID of the integration within the service. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve license allocations **Slug:** `PAGERDUTY_RETRIEVE_LICENSE_ALLOCATIONS` Retrieves the current license allocations for the PagerDuty account, showing which users have been allocated which licenses. Use this endpoint to audit license usage, track license distribution, or manage license allocation across your organization. The response includes: - A list of license allocations with user references, license details (name, valid roles, role group), and allocation timestamps - Pagination information (limit, offset, total count, and whether more results exist) This is a read-only endpoint - it does not modify license allocations. Use the optional limit and offset parameters to paginate through results for accounts with many license allocations. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | Maximum number of license allocations to return per page (default: 100 if not specified). | | `offset` | integer | No | Starting position for pagination. Use 0 for the first page, then increment by limit value for subsequent pages. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve list of services **Slug:** `PAGERDUTY_RETRIEVE_LIST_OF_SERVICES` Retrieves a list of services configured in the PagerDuty account. This endpoint allows you to fetch details about various services set up for incident management and alerting. It's particularly useful for getting an overview of all services, their configurations, and associated teams or escalation policies. The endpoint supports filtering, sorting, and pagination to manage large sets of services efficiently. Use this when you need to audit existing services, prepare for bulk updates, or integrate service information into other systems. Note that the response may not include full details of each service, and separate API calls might be necessary to fetch comprehensive information for individual services. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `name` | string | No | Filters the results, showing only services with the specified name. | | `limit` | integer | No | The number of results per page. | | `query` | string | No | Filters the result, showing only the records whose name matches the query. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | | `include` | string ("escalation_policies" | "teams" | "integrations" | "auto_pause_notifications_parameters") | No | Array of additional details to include. | | `sort_by` | string ("name" | "name:asc" | "name:desc") | No | Used to specify the field you wish to sort the results on. | | `team__ids` | array | No | An array of team IDs. Only results related to these teams will be returned. Account must have the `teams` ability to use this parameter. | | `time_zone` | string | No | Time zone in which results will be rendered. This will default to the account time zone. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve log entry by id **Slug:** `PAGERDUTY_RETRIEVE_LOG_ENTRY_BY_ID` Retrieves detailed information about a specific log entry in the PagerDuty system. This endpoint is used to access the complete record of an event or action that occurred within PagerDuty, such as incident updates, user actions, or system changes. It's particularly useful for auditing purposes, investigating specific actions taken during incident management, or gathering detailed information about system activities. The endpoint returns a single log entry based on the provided ID, allowing for precise tracking and analysis of individual events within the incident management lifecycle. Note that this endpoint is not designed for real-time monitoring or bulk log retrieval; it's intended for accessing specific, historical log entries when detailed information about a particular event is required. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `include` | string ("incidents" | "services" | "channels" | "teams") | No | Array of additional Models to include in response. | | `time_zone` | string | No | Time zone in which results will be rendered. This will default to the account time zone. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve maintenance windows **Slug:** `PAGERDUTY_RETRIEVE_MAINTENANCE_WINDOWS` Retrieves a list of maintenance windows from the PagerDuty incident management platform. Maintenance windows are scheduled periods during which alerts and notifications for specified services are suppressed to allow for system maintenance or updates without triggering unnecessary incidents. This endpoint should be used to get an overview of all maintenance windows, their schedules, and affected services. It supports filtering by team, service, and search query, as well as pagination for handling large result sets. The endpoint is particularly useful for reviewing upcoming maintenance schedules, auditing past maintenance windows, or integrating maintenance information into external systems or dashboards. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `query` | string | No | Filters the result, showing only the records whose name matches the query. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `filter` | string ("past" | "future" | "ongoing" | "open" | "all") | No | Only return maintenance windows in a given state. | | `offset` | integer | No | Offset to start pagination search results. | | `include` | string ("teams" | "services" | "users") | No | Array of additional Models to include in response. | | `team__ids` | array | No | An array of team IDs. Only results related to these teams will be returned. Account must have the `teams` ability to use this parameter. | | `service__ids` | array | No | An array of service IDs. Only results related to these services will be returned. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve notes for incident **Slug:** `PAGERDUTY_RETRIEVE_NOTES_FOR_INCIDENT` Retrieves all notes associated with a specific incident in PagerDuty. This endpoint allows users to access the complete history of comments, updates, and additional information added to an incident throughout its lifecycle. It is particularly useful for reviewing the incident's progress, understanding the actions taken, and gathering context for post-incident analysis. The endpoint should be used when detailed information about an incident's communication trail is needed, such as during incident reviews or when compiling reports. It does not provide real-time updates and may not include the most recent notes if called immediately after a new note is added due to potential API caching. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The incident ID to retrieve notes from. You can obtain incident IDs from the list incidents action or incident-related actions. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve notifications **Slug:** `PAGERDUTY_RETRIEVE_NOTIFICATIONS` Retrieves a list of notifications sent to users in PagerDuty within a specified date range. This endpoint returns notifications that were delivered via email, SMS, phone, or push notifications for incidents, alerts, and other PagerDuty events. Use this to: - Track which users were notified about specific incidents - Audit notification delivery history - Monitor notification patterns and volume - Verify that critical alerts were properly communicated to on-call responders The endpoint requires a date range (must be less than 3 months) and supports filtering by notification type, pagination, and timezone specification. Note that there may be a slight delay between when a notification is sent and when it appears in the API results. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | Maximum number of results per page (default: 25, max: 100). | | `since` | string | Yes | Start of the date range in ISO 8601 format (e.g., '2026-01-15T00:00:00Z' or '2026-01-15'). Required. The time element is optional. | | `total` | boolean | No | Whether to include the total count of notifications in the response. Set to true to get the total count, false for faster response times (default: false). | | `until` | string | Yes | End of the date range in ISO 8601 format (e.g., '2026-01-29T23:59:59Z' or '2026-01-29'). Required. Must be in the same format as 'since'. The date range must be less than 3 months. | | `filter` | string ("sms_notification" | "email_notification" | "phone_notification" | "push_notification") | No | Filter to retrieve only notifications of a specific type: 'email_notification', 'sms_notification', 'phone_notification', or 'push_notification'. | | `offset` | integer | No | Number of results to skip for pagination (default: 0). | | `include` | string ("users") | No | Additional details to include in the response. Currently supports: 'users'. | | `time_zone` | string | No | Time zone for rendering results (e.g., 'UTC', 'America/New_York', 'Europe/London'). Defaults to the account time zone if not specified. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve oncall handoff notification rule **Slug:** `PAGERDUTY_RETRIEVE_ONCALL_HANDOFF_NOTIFICATION_RULE` Retrieves detailed information about a specific on-call handoff notification rule for a given user in PagerDuty. This endpoint is crucial for managing and reviewing the notification settings that govern how users are alerted during on-call responsibility transitions. It provides access to the configuration of rules that determine when and how a user is notified about upcoming on-call shifts or handoffs. This tool should be used when there's a need to inspect or audit the notification preferences for on-call transitions of a particular user. It's particularly useful for team leads or administrators who need to ensure smooth handoffs between team members during critical incident management periods. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The user ID whose on-call handoff notification rule to retrieve. | | `oncall_handoff_notification_rule_id` | string | Yes | The oncall handoff notification rule ID on the user. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve oncall handoff notification rules **Slug:** `PAGERDUTY_RETRIEVE_ONCALL_HANDOFF_NOTIFICATION_RULES` Retrieves the on-call handoff notification rules for a specific user in PagerDuty. This endpoint allows you to fetch the configured rules that determine how and when a user is notified about on-call schedule transitions. It's particularly useful for understanding and auditing a user's notification preferences during shift changes or when responsibilities are transferred between team members. The retrieved rules may include settings for different notification methods (e.g., email, SMS, push notifications) and timing preferences relative to the handoff. This endpoint should be used when you need to review or manage a user's on-call handoff communication settings, but it does not allow for modification of these rules. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve oncall list **Slug:** `PAGERDUTY_RETRIEVE_ONCALL_LIST` Retrieves the current on-call information for your PagerDuty account. This endpoint provides a comprehensive view of who is currently on-call across various schedules and escalation policies. It's particularly useful for getting an overview of your organization's current on-call status, identifying who is responsible for incident response at any given time, and planning team availability. The endpoint supports filtering by users, escalation policies, and schedules, making it versatile for different querying needs. It also allows for pagination and including additional details like contact methods and schedule information. This tool should be used when you need to quickly assess the current on-call situation or gather data for on-call analytics. Note that while it provides current and near-future on-call information, it may not be suitable for long-term scheduling or historical analysis beyond a 3-month window. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `since` | string | No | The start of the time range over which you want to search. If an on-call period overlaps with the range, it will be included in the result. Defaults to current time. On-call shifts are limited to 90 days in the future. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `until` | string | No | The end of the time range over which you want to search. If an on-call period overlaps with the range, it will be included in the result. Defaults to current time. On-call shifts are limited to 90 days in the future, and the `until` time cannot be before the `since` time. | | `offset` | integer | No | Offset to start pagination search results. | | `include` | string ("escalation_policies" | "users" | "schedules") | No | Options for including additional details in the response. - escalation_policies: Include full escalation policy details - users: Include full user details with contact methods - schedules: Include full schedule details | | `earliest` | boolean | No | This will filter on-calls such that only the earliest on-call for each combination of escalation policy, escalation level, and user is returned. This is useful for determining when the "next" on-calls are for a given set of filters. | | `user_ids` | array | No | Filters the results, showing only on-calls for the specified user IDs. | | `time_zone` | string | No | Time zone in which results will be rendered. This will default to the account time zone. | | `schedule_ids` | array | No | Filters the results, showing only on-calls for the specified schedule IDs. If `null` is provided in the array, it includes permanent on-calls due to direct user escalation targets. | | `escalation_policy_ids` | array | No | Filters the results, showing only on-calls for the specified escalation policy IDs. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve past incidents **Slug:** `PAGERDUTY_RETRIEVE_PAST_INCIDENTS` Retrieves a list of past similar incidents for a specific incident using machine learning. This endpoint uses PagerDuty's AIOps-powered Past Incidents feature to find historical incidents from the same service that are similar to the current incident. The similarity is determined by analyzing incident title semantics, responders, duration, and timing. **Requirements:** - Requires PagerDuty AIOps add-on subscription - The service must have AIOps enabled in its configuration **Use Cases:** - Identify recurring problems and patterns - Find similar historical incidents for context during incident response - Analyze incident patterns for root cause analysis - Learn from past incident resolutions **Note:** This endpoint returns ML-generated similar past incidents, not all past incidents. For retrieving all incidents, use the 'Fetch incident list' action instead. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident for which to retrieve past similar incidents. | | `limit` | integer | No | The maximum number of past incidents to return in the response. Default is 5. | | `total` | boolean | No | Whether to include the total count of past incidents in the response. By default this is set to `false` to provide faster response times. Set to `true` to populate the total count field. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve postmortem by id **Slug:** `PAGERDUTY_RETRIEVE_POSTMORTEM_BY_ID` Retrieves the postmortem analysis for a specific post on a PagerDuty status page. This endpoint allows users to access detailed information about an incident after it has been resolved, including root cause analysis, timeline of events, and lessons learned. It should be used when detailed information about the resolution of a specific incident is needed, particularly for review, documentation, or improvement purposes. The endpoint is valuable for teams conducting thorough post-incident reviews or for maintaining a knowledge base of past incidents and their resolutions. Note that this endpoint only provides postmortem information and does not allow for modifications to the postmortem content. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the Status Page containing the post. You can obtain status page IDs using the 'Fetch status pages' action. | | `post_id` | string | Yes | The ID of the Status Page Post that has a postmortem. You can obtain post IDs from status page post creation or listing actions. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve response play by id **Slug:** `PAGERDUTY_RETRIEVE_RESPONSE_PLAY_BY_ID` **DEPRECATED**: This endpoint has been deprecated and removed. Response Plays have been replaced by Incident Workflows. When calling this endpoint, the API returns HTTP 301 (Moved Permanently) with the error message: "Incident Workflows are enabled on this account." **Migration Path**: Use Incident Workflows API instead: - List Incident Workflows: GET /incident_workflows - Get Incident Workflow: GET /incident_workflows/{id} **Original Functionality**: This endpoint previously retrieved detailed information about a specific response play in the PagerDuty incident management system, including configuration and actions for automating incident response processes. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the response play to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve rule by service id **Slug:** `PAGERDUTY_RETRIEVE_RULE_BY_SERVICE_ID` Retrieves a specific service event rule by ID from a PagerDuty service. Service Event Rules configure how incoming events are processed, including setting severity and priority based on conditions. **Important:** This accesses the legacy Service Event Rules system (EOL Jan 31, 2025). The GET API remains available for reading existing rules, but new rule creation is disabled. For new implementations, use Event Orchestration (PAGERDUTY_GET_THE_SERVICE_ORCHESTRATION_FOR_A_SERVICE). **Use Cases:** Audit existing rules, retrieve rule details before migrating to Event Orchestration, review historical settings, troubleshoot legacy workflows. **Note:** This retrieves a single rule. Use PAGERDUTY_RETRIEVE_RULES_FOR_SERVICE_ID to list all rules for a service. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The service ID. This identifies the PagerDuty service whose event rule you want to retrieve. | | `rule_id` | string | Yes | The event rule ID. This identifies the specific service event rule to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve ruleset by id **Slug:** `PAGERDUTY_RETRIEVE_RULESET_BY_ID` Retrieves detailed information about a specific ruleset in PagerDuty using its unique identifier. This endpoint allows you to fetch the complete configuration and settings of a single ruleset, which is essential for understanding how incident responses are automated and managed. Use this when you need to review, audit, or troubleshoot a particular ruleset's configuration. The response will include all relevant details such as the ruleset's name, type, routing keys, and associated rules. It's particularly useful when you need to examine the exact setup of a ruleset without making any changes. Note that this endpoint only provides read access and cannot be used to modify the ruleset. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve ruleset list **Slug:** `PAGERDUTY_RETRIEVE_RULESET_LIST` Retrieves a list of rulesets from the PagerDuty system. Rulesets are collections of event rules that define how incidents are managed and alerts are configured. This endpoint allows you to view all available rulesets, which is crucial for understanding your incident management setup and making informed decisions about alert routing and event handling. Use this endpoint when you need to audit your ruleset configurations, prepare for modifications to your incident management workflow, or simply need an overview of your current ruleset structure. The response will include details about each ruleset, such as its name, ID, and potentially its associated rules, depending on the API version and configuration. This endpoint supports pagination to handle large numbers of rulesets efficiently. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve rules for service id **Slug:** `PAGERDUTY_RETRIEVE_RULES_FOR_SERVICE_ID` Retrieves all rules associated with a specific PagerDuty service. This endpoint allows users to fetch the set of rules that define when and how incidents are triggered for a particular service. It's essential for understanding the current automation and alert routing setup for a given service. Use this endpoint when you need to audit, review, or programmatically access the rule configurations for a service. The endpoint returns rule details but does not provide information about ongoing incidents or service status. It's particularly useful for integrations that need to sync or analyze rule configurations across multiple services or external systems. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `limit` | integer | No | The number of results per page. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | | `include` | string ("migrated_metadata") | No | Array of additional Models to include in response. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve rules from ruleset by id **Slug:** `PAGERDUTY_RETRIEVE_RULES_FROM_RULESET_BY_ID` Retrieves a list of event rules associated with a specific ruleset in PagerDuty. **Note**: Rulesets reached end-of-life on January 31, 2025 and are no longer visible in the PagerDuty web app. However, read-only API access is still available for existing rulesets. New rulesets cannot be created. PagerDuty recommends migrating to Event Orchestration for ongoing event routing configuration. This endpoint returns information about each rule in a ruleset, including: - Rule conditions that determine when the rule applies - Actions to execute when conditions are met - Rule ordering/position - Active/disabled status **Use Cases**: - Audit existing event routing configuration - Document legacy ruleset behavior before migration - Troubleshoot event routing issues with existing rulesets The response supports pagination for rulesets with many rules. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `limit` | integer | No | The number of results per page. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve schedule audit records by id **Slug:** `PAGERDUTY_RETRIEVE_SCHEDULE_AUDIT_RECORDS_BY_ID` Retrieves the audit records for a specific PagerDuty schedule. This endpoint allows you to access a comprehensive log of all changes made to the specified schedule, including modifications to on-call rotations, time periods, and associated team members. It's particularly useful for compliance purposes, tracking historical changes, and understanding how the schedule has evolved over time. The returned data typically includes details such as the timestamp of each change, the user who made the modification, and the specific alterations made to the schedule. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `limit` | integer | No | The minimum of the `limit` parameter used in the request or the maximum request size of the API. | | `since` | string | No | The start of the date range over which you want to search. If not specified, defaults to `now() - 24 hours` (past 24 hours) | | `until` | string | No | The end of the date range over which you want to search. If not specified, defaults to `now()`. May not be more than 31 days after `since`. | | `cursor` | string | No | Optional parameter used to request the "next" set of results from an API. The value provided here is most commonly obtained from the `next_cursor` field of the previous request. When no value is provided, the request starts at the beginning of the result set. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve schedule by id **Slug:** `PAGERDUTY_RETRIEVE_SCHEDULE_BY_ID` Retrieves detailed information about a specific schedule in PagerDuty using its unique identifier. This endpoint is essential for viewing the configuration of an existing on-call schedule, including its name, time periods, rotation layers, and associated users or teams. Use this when you need to inspect a schedule's current setup, verify on-call assignments, or gather data for schedule management tasks. The endpoint provides a comprehensive view of a single schedule but does not allow modifications; for updates, a separate PUT request would be required. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `since` | string | No | The start of the date range over which you want to show schedule entries. Defaults to 2 weeks before until if an until is given. | | `until` | string | No | The end of the date range over which you want to show schedule entries. Defaults to 2 weeks after since if a since is given. | | `overflow` | boolean | No | Any on-call schedule entries that pass the date range bounds will be truncated at the bounds, unless the parameter `overflow=true` is passed. This parameter defaults to false. For instance, if your schedule is a rotation that changes daily at midnight UTC, and your date range is from `2011-06-01T10:00:00Z` to `2011-06-01T14:00:00Z`: - If you don"t pass the `overflow=true` parameter, you will get one schedule entry returned with a start of `2011-06-01T10:00:00Z` and end of `2011-06-01T14:00:00Z`. - If you do pass the `overflow=true` parameter, you will get one schedule entry returned with a start of `2011-06-01T00:00:00Z` and end of `2011-06-02T00:00:00Z`. | | `time_zone` | string | No | Time zone in which results will be rendered. This will default to the schedule"s time zone. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve schedule override by id **Slug:** `PAGERDUTY_RETRIEVE_SCHEDULE_OVERRIDE_BY_ID` Lists all schedule overrides for a specific schedule within a date range. Schedule overrides are temporary modifications to the regular on-call rotation, allowing you to assign different users for specific time periods without changing the base schedule. Use this action to: - View all temporary schedule changes within a specific time period - Audit who was or will be on-call during override periods - Verify that schedule modifications have been correctly applied - Plan future on-call coverage by checking existing overrides The action returns a list of overrides, each containing the override ID, start/end times, and the user assigned during that period. You can filter results using optional parameters: 'editable' returns only future overrides that can be modified, and 'overflow' controls whether overrides extending beyond the date range are truncated or fully included. Note: This is a read-only operation - it does not create, modify, or delete overrides. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the schedule to retrieve overrides for. | | `since` | string | Yes | The start of the date range in ISO 8601 format (e.g., '2026-02-01T00:00:00Z'). Use this to define the beginning of the time window to search for overrides. | | `until` | string | Yes | The end of the date range in ISO 8601 format (e.g., '2026-02-28T23:59:59Z'). Use this to define the end of the time window to search for overrides. | | `editable` | boolean | No | When this parameter is present, only editable overrides will be returned. The result will only include the id of the override if this parameter is present. Only future overrides are editable. | | `overflow` | boolean | No | Any on-call schedule entries that pass the date range bounds will be truncated at the bounds, unless the parameter overflow=true is passed. This parameter defaults to false. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve service audit records by id **Slug:** `PAGERDUTY_RETRIEVE_SERVICE_AUDIT_RECORDS_BY_ID` Retrieves the audit records for a specific PagerDuty service. This endpoint allows you to fetch a historical log of all configuration changes made to the service, providing transparency and accountability in incident management processes. Use this endpoint when you need to review modifications, track who made changes, or investigate the evolution of a service's configuration over time. The audit records are typically sorted by execution time from newest to oldest, offering a chronological view of alterations. While this endpoint is valuable for compliance and debugging purposes, it does not provide real-time incident data or current service configurations. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the service to retrieve audit records for. | | `limit` | integer | No | The number of audit records to return per page. Default and maximum values are determined by the API. Use this with the cursor parameter for pagination. | | `since` | string | No | The start of the date range over which you want to search, in ISO 8601 format (e.g., '2024-01-01T00:00:00Z'). If not specified, defaults to now() - 24 hours. | | `until` | string | No | The end of the date range over which you want to search, in ISO 8601 format (e.g., '2024-01-31T23:59:59Z'). If not specified, defaults to now(). May not be more than 31 days after the 'since' parameter. | | `cursor` | string | No | Optional parameter used to request the "next" set of results from an API. The value provided here is most commonly obtained from the `next_cursor` field of the previous request. When no value is provided, the request starts at the beginning of the result set. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve service by id **Slug:** `PAGERDUTY_RETRIEVE_SERVICE_BY_ID` Retrieves detailed information about a specific PagerDuty service using its unique identifier. This endpoint allows users to access configuration details, integration settings, and other relevant information for a particular service within their PagerDuty account. It's essential for managing and monitoring the status of individual services, which are core components in PagerDuty's incident management system. Use this endpoint when you need to inspect or verify the configuration of a specific service, such as before making updates or troubleshooting issues related to that service. The endpoint provides a comprehensive view of the service but does not allow modifications; for updates, a separate PUT or PATCH endpoint would be required. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the PagerDuty service to retrieve. This is a unique identifier for the service (e.g., 'PG9JLO3'). | | `include` | string ("escalation_policies" | "teams" | "auto_pause_notifications_parameters" | "integrations") | No | Optional parameter to include additional related details in the response. Options: 'escalation_policies' (full escalation policy details with rules and targets), 'teams' (full team details with names and descriptions), 'integrations' (all integrations configured for the service), 'auto_pause_notifications_parameters' (auto-pause notification configuration if enabled). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve service change events by id **Slug:** `PAGERDUTY_RETRIEVE_SERVICE_CHANGE_EVENTS_BY_ID` Retrieves change events associated with a specific PagerDuty service. This endpoint allows you to fetch informational updates about recent changes such as code deploys, system configuration modifications, and other significant alterations related to the specified service. It's particularly useful for tracking and auditing changes that might impact service performance or reliability. The endpoint should be used when you need to review the history of changes for a service, investigate potential causes of incidents, or maintain a log of service modifications for compliance purposes. Note that this endpoint focuses solely on change events and does not provide real-time incident data or service configuration details. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `limit` | integer | No | The number of results per page. | | `since` | string | No | The start of the date range over which you want to search, as a UTC ISO 8601 datetime string. Will return an HTTP 400 for non-UTC datetimes. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `until` | string | No | The end of the date range over which you want to search, as a UTC ISO 8601 datetime string. Will return an HTTP 400 for non-UTC datetimes. | | `offset` | integer | No | Offset to start pagination search results. | | `team__ids` | array | No | An array of team IDs. Only results related to these teams will be returned. Account must have the `teams` ability to use this parameter. | | `integration__ids` | array | No | An array of integration IDs. Only results related to these integrations will be returned. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve service impacts from status dashboards **Slug:** `PAGERDUTY_RETRIEVE_SERVICE_IMPACTS_FROM_STATUS_DASHBOARDS` Retrieves the service impacts associated with a specific status dashboard in PagerDuty. This endpoint allows users to fetch detailed information about how incidents are affecting various services within the context of a particular status dashboard. It should be used when there's a need to assess the current operational status and impact of incidents on services for a given dashboard. The endpoint provides real-time insights into service disruptions, helping teams quickly identify and prioritize issues. Note that this endpoint only returns data for a single status dashboard at a time and does not provide historical impact data. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status dashboard to retrieve service impacts from. | | `additional__fields` | array | No | Provides access to additional fields such as highest priority per business service and total impacted count. Multiple values can be specified. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve service status by id **Slug:** `PAGERDUTY_RETRIEVE_SERVICE_STATUS_BY_ID` Retrieves a list of services associated with a specific status page in PagerDuty. This endpoint fetches all services that are being monitored and displayed on a particular status page. Status pages provide real-time visibility into service health and operational status. The response includes service details such as names, current statuses, and relevant metadata. Use this action when you need to: - Review which services are shown on a specific status page - Monitor the operational status of services on a status page - Integrate status page service information with external systems - Audit service visibility configurations Note: You must have access to the specified status page. Use the PAGERDUTY_FETCH_STATUS_PAGES action to get available status page IDs. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page for which to retrieve associated services. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve service status page **Slug:** `PAGERDUTY_RETRIEVE_SERVICE_STATUS_PAGE` Retrieves detailed information about a specific service associated with a particular status page in PagerDuty. This endpoint is used to fetch the current status, configuration, and other relevant details of a service displayed on a status page. It's particularly useful for monitoring the health and state of individual components within a larger system. The endpoint should be used when you need up-to-date information about a specific service's status or when integrating PagerDuty's status information into other monitoring or reporting tools. Note that this endpoint only provides information for services that are configured to be displayed on the specified status page. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page. This is a unique identifier for the status page that contains the service you want to retrieve. | | `service_id` | string | Yes | The ID of the service within the status page. This identifies the specific business service or technical service that is displayed on the status page. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve standards list **Slug:** `PAGERDUTY_RETRIEVE_STANDARDS_LIST` Retrieves the current set of Service Standards defined in the PagerDuty account. Service Standards are configurable criteria that help organizations define, share, and track service configuration best practices. These standards ensure consistency across services and improve incident response predictability. Standards can check for various service attributes such as having descriptions, proper escalation policies, integrations, dependencies, and more. This endpoint returns standards that can be filtered by active status and resource type. Each standard includes details about what it checks, why it's important, and which resources are included or excluded from its scope. Administrators and team leads use this to review and audit service configuration standards across their organization. Note: This endpoint is read-only and does not allow modification of standards. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `active` | boolean | No | Filter standards by active status. Set to true to retrieve only active standards, false for inactive standards, or omit to retrieve all standards. | | `resource_type` | string ("technical_service") | No | Filter standards by resource type. Currently supports 'technical_service' to retrieve standards applicable to technical services. Omit to retrieve standards for all resource types. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve standards scores by resource type and id **Slug:** `PAGERDUTY_RETRIEVE_STANDARDS_SCORES` Retrieves the standards scores for a specific technical service in PagerDuty. Returns a detailed evaluation showing which PagerDuty best practices and standards the service meets, including whether it has proper descriptions, escalation policies, integrations, and service dependencies. Each standard includes a pass/fail status and explanation. Use this to assess service health, identify configuration gaps, and ensure services follow organizational best practices. The response includes a score summary (e.g., "passing 4 out of 9 standards") and detailed results for each evaluated standard. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the technical service to retrieve standards scores for. | | `resource_type` | string ("technical_services") | Yes | The type of resource to retrieve standards for. Currently only supports "technical_services". | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve standards scores by resourcetype **Slug:** `PAGERDUTY_RETRIEVE_STANDARDS_SCORES_BY_RESOURCE_TYPE` Retrieves the standards scores for a specified resource type in PagerDuty. This endpoint allows users to access performance metrics and evaluations based on predefined standards for different components of their incident management system. It's useful for assessing the effectiveness of various resources against established benchmarks, helping teams identify areas for improvement and maintain high-quality incident response processes. The endpoint should be used when seeking quantitative insights into the performance of specific PagerDuty resource types against industry or internal standards. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `ids` | array | Yes | Ids of resources to apply the standards. Maximum of 100 items | | `resource_type` | string ("technical_services") | Yes | Resource Type | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve status dashboard by slug **Slug:** `PAGERDUTY_RETRIEVE_STATUS_DASHBOARD_BY_SLUG` Retrieves detailed information about a specific PagerDuty status dashboard using its URL slug. This endpoint allows users to fetch the current state, components, and other relevant data associated with a particular status dashboard. It's useful for integrating PagerDuty's status information into external monitoring systems or custom dashboards. The endpoint should be used when you need to programmatically access up-to-date information about a known status dashboard. Note that this endpoint only provides information for existing dashboards and does not create or modify dashboard data. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `url_slug` | string | Yes | The URL slug identifier for the status dashboard (e.g., 'nasa'). This is a case-insensitive string that uniquely identifies a status dashboard. You can obtain valid URL slugs by listing all status dashboards first. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve status dashboards information **Slug:** `PAGERDUTY_RETRIEVE_STATUS_DASHBOARDS_INFORMATION` Retrieves a list of status dashboards and their associated information from the PagerDuty system. This endpoint provides a comprehensive overview of the current operational status, performance metrics, and health indicators across various systems or services monitored by PagerDuty. It's particularly useful for obtaining a high-level view of system status without diving into specific incidents or alerts. The endpoint should be used when you need to quickly assess the overall health of your monitored systems, identify any ongoing issues or incidents, and get a snapshot of key performance indicators. It's ideal for regular system checks, creating status pages, or integrating system health information into other monitoring tools. While this endpoint offers a broad view of system status, it may not provide detailed information about specific incidents or historical data. For in-depth analysis of particular issues or long-term trends, you may need to use other specialized endpoints. #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve status page post **Slug:** `PAGERDUTY_RETRIEVE_STATUS_PAGE_POST` Retrieves all posts associated with a specific status page in PagerDuty. This endpoint allows you to fetch updates, messages, and status information that have been posted to a particular status page. Use this to monitor the history of service status updates, incident communications, or maintenance notices for a given status page. The endpoint returns a list of posts with details including post content, title, type, timestamps, impacted services, severity, and status updates. You can filter results by post type (incident or maintenance), review status, or specific status IDs. This is a read-only endpoint and cannot be used to create, modify, or delete posts. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page from which to retrieve posts. You can get status page IDs from the 'Fetch Status Pages' action. | | `status` | array | No | Filter posts by an array of status IDs (e.g., ['investigating', 'identified', 'monitoring', 'resolved'] for incidents, or status IDs for maintenance). You can get available status IDs from the 'List Status Page Statuses' action. If not specified, returns posts with any status. | | `post_type` | string ("incident" | "maintenance") | No | Filter posts by type: 'incident' for service disruption posts or 'maintenance' for scheduled maintenance posts. If not specified, returns all post types. | | `reviewed_status` | string ("approved" | "not_reviewed") | No | Filter posts by review status: 'approved' for posts that have been reviewed and approved, or 'not_reviewed' for posts awaiting review. If not specified, returns posts with any review status. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve status page severities by id **Slug:** `PAGERDUTY_RETRIEVE_STATUS_PAGE_SEVERITIES_BY_ID` Retrieves the list of severities associated with a specific status page in PagerDuty. This endpoint allows users to fetch the current severity levels configured for a particular status page, which is crucial for understanding the criticality of incidents or service statuses displayed on that page. It should be used when there's a need to programmatically access or display the severity information for a given status page, such as in monitoring dashboards or integrated incident management systems. The endpoint provides only the severity data and does not modify any existing configurations. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page whose severities you want to retrieve. | | `post_type` | string ("incident" | "maintenance") | No | Optional filter to retrieve severities by post type. Use 'incident' for incident posts or 'maintenance' for maintenance posts. If not specified, returns severities for all post types. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve status pages status **Slug:** `PAGERDUTY_RETRIEVE_STATUS_PAGES_STATUS` Retrieves the current statuses for a specified PagerDuty status page. This endpoint allows users to fetch real-time status information for a given status page, providing up-to-date details on service availability and any ongoing issues. It's particularly useful for monitoring the current state of services, especially during incident management processes. The endpoint should be used when there's a need to programmatically access the latest status information for a specific status page, enabling integration with other systems or dashboards for enhanced visibility of service health. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page to retrieve statuses for. | | `post_type` | string ("incident" | "maintenance") | No | Optional filter to return only statuses for posts of a specific type (incident or maintenance). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve status page subscription by id **Slug:** `PAGERDUTY_RETRIEVE_STATUS_PAGE_SUBSCRIPTION_BY_ID` Retrieves a list of subscriptions associated with a specific PagerDuty status page. This endpoint allows users to fetch all current subscriptions for a given status page, enabling them to monitor who is receiving updates about the status page. It should be used when you need to review or audit the subscription list for a particular status page. The endpoint provides subscription details but does not allow for modification of subscriptions. Note that the response may be paginated for status pages with a large number of subscriptions. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `status` | string ("active" | "pending") | No | Filter by Subscription status. | | `channel` | string ("webhook" | "email" | "slack") | No | Filter by Subscription channel. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve tag by id **Slug:** `PAGERDUTY_RETRIEVE_TAG_BY_ID` Retrieves detailed information about a specific tag in the PagerDuty system using its unique identifier. This endpoint allows users to fetch the properties and metadata associated with a particular tag, which can be useful for incident management, reporting, and organization within PagerDuty. It should be used when detailed information about a specific tag is needed, such as its name, description, or any custom attributes. The endpoint will not modify or create tags; it is purely for retrieval of existing tag data. Note that the response will only include information for tags that the authenticated user has permission to view. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the tag to retrieve (e.g., 'PTFK5EW') | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve tags **Slug:** `PAGERDUTY_RETRIEVE_TAGS` Retrieves a list of tags from your PagerDuty account with optional filtering and pagination. Tags are used to categorize and label entities such as teams, users, and escalation policies in PagerDuty. This endpoint is useful when you need to browse available tags, search for specific tags by label, or build tag selection interfaces. Supports filtering by tag label using the 'query' parameter and pagination using 'limit' and 'offset' parameters. The response includes tag IDs, labels, and API URLs which can be used with other tag-related endpoints. Note: This endpoint returns tag definitions only, not information about which entities are tagged with them. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. Default is 100 if not specified. | | `query` | string | No | Filters the result, showing only the tags whose label matches the query. If not specified, all tags are returned. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. Default is 0 if not specified. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve team audit records **Slug:** `PAGERDUTY_RETRIEVE_TEAM_AUDIT_RECORDS` Retrieves the audit records for a specific team in PagerDuty. This endpoint allows users to access a detailed history of configuration changes made to the team, including modifications to team members, escalation policies, and other team-related settings. It's particularly useful for security auditing, compliance reporting, and tracking the evolution of team structures over time. The endpoint returns a list of audit records, each likely containing information such as the type of change, who made the change, and when it occurred. Use this endpoint when you need to review or analyze the historical changes of a PagerDuty team's configuration. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the team for which to retrieve audit records. | | `limit` | integer | No | The maximum number of audit records to return per page. If not specified, the API will use its default page size. | | `since` | string | No | The start of the date range over which you want to search, in ISO 8601 format (e.g., '2024-01-15T00:00:00Z'). If not specified, defaults to 24 hours ago. | | `until` | string | No | The end of the date range over which you want to search, in ISO 8601 format (e.g., '2024-01-31T23:59:59Z'). If not specified, defaults to now. Must not be more than 31 days after 'since'. | | `cursor` | string | No | Optional parameter used to request the "next" set of results from an API. The value provided here is most commonly obtained from the `next_cursor` field of the previous request. When no value is provided, the request starts at the beginning of the result set. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve team details by id **Slug:** `PAGERDUTY_RETRIEVE_TEAM_DETAILS_BY_ID` Retrieves detailed information about a specific team in PagerDuty based on the provided team ID. This endpoint allows users to fetch comprehensive data about a team, including its members, roles, and configurations. It is particularly useful for applications that need to display or process team information, such as team management dashboards or reporting tools. The endpoint returns all available details about the specified team, providing a snapshot of its current state within the PagerDuty system. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the team to retrieve. | | `include` | string ("privileges") | No | Include additional information in the response. Use 'privileges' to include team member privileges and roles. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve team list **Slug:** `PAGERDUTY_RETRIEVE_TEAM_LIST` The ListTeams endpoint retrieves a list of teams within a PagerDuty account. It provides an overview of all teams or a filtered subset based on the optional query parameter. This endpoint is useful for obtaining team information, such as team names and IDs, which can be used in other API calls or for organizational purposes. The response typically includes basic details about each team, allowing for further actions or more detailed queries on specific teams. Use this endpoint when you need to survey the teams in your PagerDuty organization, prepare for team management tasks, or integrate team information into other systems. Note that while it returns a list of teams, it may not provide exhaustive details for each team; for comprehensive information on a specific team, a separate API call might be necessary. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `query` | string | No | Filters the result, showing only the records whose name matches the query. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve technical service details **Slug:** `PAGERDUTY_RETRIEVE_TECHNICAL_SERVICE_DETAILS` Retrieves detailed information about a specific technical service and its dependencies within the PagerDuty incident management platform. This endpoint is used to fetch comprehensive data about a single technical service, including its relationships with other services, its role in the overall service dependency structure, and any associated metadata. It's particularly useful for understanding the impact and connections of a specific service within an organization's technical infrastructure. The endpoint should be used when detailed information about a particular technical service's dependencies and relationships is needed, such as during incident analysis, service mapping, or system architecture reviews. It does not modify any data and is safe for frequent use in monitoring or dashboard applications. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the technical service to retrieve dependency information for. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve template fields **Slug:** `PAGERDUTY_RETRIEVE_TEMPLATE_FIELDS` Retrieves the available field definitions for PagerDuty status update templates. This endpoint returns metadata about the fields that can be used when creating or modifying templates within the PagerDuty platform. **Important**: This endpoint requires PagerDuty's Status Pages or Templates feature, which is typically available on Business or Enterprise plans. If the feature is not available on your account, the API will return a 402 Payment Required error. The endpoint is useful for: - Understanding available template field options before creating templates - Building interfaces for template management - Automating template creation with proper field validation - Documenting the template schema for your organization This is a read-only endpoint that does not modify any existing templates or create new ones; it only provides information about the available field definitions and their properties (such as field names, types, and descriptions). #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve unrouted event orchestration by id **Slug:** `PAGERDUTY_RETRIEVE_UNROUTED_EVENT_ORCHESTRATION_BY_ID` Retrieves the unrouted orchestration configuration for a specific Event Orchestration in PagerDuty. The unrouted orchestration defines how events that don't match any routing rules are handled - they can be suppressed or routed to specific services. This configuration includes rule sets, catch-all actions, and version information. Use this endpoint when you need to review or audit the unrouted event handling configuration, understand how unmatched events are processed, or before updating the unrouted orchestration rules. The endpoint returns the complete configuration including created/updated timestamps, user references, and the current version identifier. Note that this is a read-only endpoint for retrieving configuration - use the update endpoint to modify the unrouted orchestration settings. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve user audit records by id **Slug:** `PAGERDUTY_RETRIEVE_USER_AUDIT_RECORDS_BY_ID` Retrieves the audit records for a specific user in the PagerDuty system. This endpoint allows you to access a historical log of activities and changes associated with the user, providing valuable insights for compliance, security, and troubleshooting purposes. The audit records may include actions such as login attempts, configuration changes, and incident-related activities performed by or affecting the specified user. Use this endpoint when you need to investigate user activities, track changes, or generate reports for auditing and compliance requirements. Note that the response may be paginated, and additional query parameters might be available to filter or sort the results, although these are not explicitly defined in the given schema. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user for which to retrieve audit records. | | `limit` | integer | No | The maximum number of audit records to return per page. If not specified, the API will use its default page size. | | `since` | string | No | The start of the date range over which you want to search, in ISO 8601 format (e.g., '2024-01-15T00:00:00Z'). If not specified, defaults to 24 hours ago. | | `until` | string | No | The end of the date range over which you want to search, in ISO 8601 format (e.g., '2024-01-31T23:59:59Z'). If not specified, defaults to now. Must not be more than 31 days after 'since'. | | `cursor` | string | No | Optional parameter used to request the "next" set of results from an API. The value provided here is most commonly obtained from the `next_cursor` field of the previous request. When no value is provided, the request starts at the beginning of the result set. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve user by id **Slug:** `PAGERDUTY_RETRIEVE_USER_BY_ID` Retrieves detailed information about a specific PagerDuty user by their ID. Returns user profile data including name, email, role, timezone, and other account details. Use the 'include' parameter to optionally fetch related resources like contact methods, notification rules, teams, or subdomains in the same request. Common use cases: - Get user profile information for display in applications - Verify user details before performing operations - Fetch user contact methods for notification purposes - Check user role and permissions Note: This endpoint does not return the user's current on-call status or incident history. Use the on-calls or incidents endpoints for that information. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user. | | `include` | array | No | Array of additional related resources to include in the response. Can include 'contact_methods', 'notification_rules', 'teams', and 'subdomains'. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve user contact methods via id **Slug:** `PAGERDUTY_RETRIEVE_USER_CONTACT_METHODS_VIA_ID` Retrieves all contact methods associated with a specific user in PagerDuty. This endpoint allows you to fetch the various ways a user can be contacted during an incident, such as email addresses, phone numbers, or push notifications to mobile devices. It's particularly useful when you need to review or update a user's notification preferences or ensure that the correct contact information is on file. The endpoint returns a list of contact methods, likely including details such as the type of contact method, the specific address or number, and possibly the status (e.g., verified, primary). It should be used when setting up new users, auditing user information, or integrating PagerDuty with other communication systems. Note that this endpoint only provides read access to contact methods and cannot be used to add, modify, or remove contact information. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve user license information **Slug:** `PAGERDUTY_RETRIEVE_USER_LICENSE_INFORMATION` Retrieves the license information for a specific user in the PagerDuty system. This endpoint allows you to check the current licensing status, type, and any associated details for a given user. It should be used when you need to verify a user's license, such as during account management or when troubleshooting access issues. The endpoint will return details about the user's current license, but it does not provide information about other aspects of the user's account or permissions. Keep in mind that access to this endpoint may be restricted to users with appropriate administrative privileges. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user whose license information you want to retrieve. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve user notification rule **Slug:** `PAGERDUTY_RETRIEVE_USER_NOTIFICATION_RULE` Retrieves a specific notification rule for a given user in PagerDuty. This endpoint allows you to fetch detailed information about how and when a particular user receives alerts and notifications. It's useful for auditing user preferences, troubleshooting notification issues, or when you need to review or potentially update a user's notification settings. The endpoint returns the configuration of the specified rule, including contact methods, time-based restrictions, and urgency levels. It should be used when you need to examine or verify the settings of a particular notification rule for a user, but it won't provide an overview of all rules or allow modifications to the rule. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user whose notification rule you want to retrieve. | | `include` | string ("contact_methods") | No | Optional. Include 'contact_methods' to expand full contact method details in the response instead of just references. | | `notification_rule_id` | string | Yes | The ID of the specific notification rule to retrieve for this user. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve user notification rules **Slug:** `PAGERDUTY_RETRIEVE_USER_NOTIFICATION_RULES` Retrieves the notification rules for a specific user in PagerDuty. This endpoint allows you to fetch all configured notification rules associated with a given user, providing insight into how and when the user receives alerts for incidents. It's particularly useful for auditing a user's notification setup, troubleshooting notification issues, or programmatically managing user preferences. The endpoint returns a list of notification rules, likely including details such as contact methods, time-based restrictions, and urgency levels for each rule. It should be used when you need to review or analyze a user's current notification configuration within your incident management workflow. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user whose notification rules to retrieve. | | `include` | string ("contact_methods") | No | Array of additional details to include. Use 'contact_methods' to include full contact method objects in the notification rules. | | `urgency` | string ("high" | "low" | "all") | No | The incident urgency for which the notification rules are applied. If not specified, defaults to `high`. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve users by schedule id **Slug:** `PAGERDUTY_RETRIEVE_USERS_BY_SCHEDULE_ID` Retrieves a list of users associated with a specific PagerDuty schedule. This endpoint is essential for managing on-call rotations and understanding who is responsible for incident response during different time periods. It should be used when you need to view all users assigned to a particular schedule, which is helpful for auditing, planning, or modifying on-call arrangements. The endpoint returns basic user information and does not provide detailed schedule timeslots or user availability. It's particularly useful for larger teams with complex rotation schedules to ensure proper coverage and fair distribution of on-call responsibilities. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the schedule to retrieve users from. | | `since` | string | No | The start of the date range over which you want to search, in ISO 8601 format (e.g., '2026-01-01T00:00:00Z'). Only users on-call during this period will be returned. | | `until` | string | No | The end of the date range over which you want to search, in ISO 8601 format (e.g., '2026-12-31T23:59:59Z'). Only users on-call during this period will be returned. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve users list **Slug:** `PAGERDUTY_RETRIEVE_USERS_LIST` Retrieves a list of users from the PagerDuty system. This endpoint allows you to fetch information about multiple users in your PagerDuty account, which can be useful for user management, generating reports, or integrating user data with other systems. The response typically includes basic information about each user, such as their ID, name, email, and role. Use query parameters to filter, paginate, or search for specific users. This endpoint is ideal for bulk operations or when you need an overview of your PagerDuty user base. Note that the results may be paginated, so multiple calls might be necessary to retrieve all users for large accounts. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `query` | string | No | Filters the result, showing only the records whose name matches the query. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | | `include` | string ("contact_methods" | "notification_rules" | "teams" | "subdomains") | No | Array of additional Models to include in response. | | `team__ids` | array | No | An array of team IDs. Only results related to these teams will be returned. Account must have the `teams` ability to use this parameter. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve user status update notification rule **Slug:** `PAGERDUTY_RETRIEVE_USER_STATUS_UPDATE_NOTIFICATION_RULE` Retrieves a specific status update notification rule for a given user in PagerDuty. This endpoint allows you to fetch detailed information about how and when a particular user receives notifications for status updates on incidents. It's useful for auditing notification settings, troubleshooting notification issues, or programmatically managing user preferences. The endpoint should be used when you need to review or verify the configuration of a single notification rule for a specific user. It does not modify any settings and is read-only in nature. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `include` | string ("contact_methods") | No | Array of additional details to include. | | `status_update_notification_rule_id` | string | Yes | The status update notification rule ID on the user. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve vendor by id **Slug:** `PAGERDUTY_RETRIEVE_VENDOR_BY_ID` Get detailed information about a specific PagerDuty vendor integration by its ID. Returns vendor details including name, description, integration type, logo URLs, documentation links, and connection capabilities. Use this to verify vendor configuration or gather integration information before setting up services. Requires a valid vendor ID (e.g., 'PZQ6AUS' for AWS CloudWatch, 'PAM4FGS' for Datadog). Get vendor IDs by first calling the fetch vendor list action. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique vendor ID (e.g., 'PZQ6AUS' for AWS CloudWatch, 'PAM4FGS' for Datadog). Use the fetch vendor list action to discover available vendor IDs. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Retrieve webhook subscriptions **Slug:** `PAGERDUTY_RETRIEVE_WEBHOOK_SUBSCRIPTIONS` Retrieves a list of all webhook subscriptions associated with the authenticated PagerDuty account. This endpoint allows users to view and manage their existing webhook configurations, which are used to receive real-time notifications about incidents, alerts, and other PagerDuty events. It's particularly useful for auditing current integrations, troubleshooting notification issues, or preparing to update webhook settings. The response likely includes details such as webhook URLs, event types they're subscribed to, and their current status. This endpoint should be used when you need an overview of all active webhook integrations but won't provide the actual event data sent to these webhooks. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | | `filter_id` | string | No | The id of the resource to filter upon. Required if filter_type is service or team. | | `filter_type` | string ("account" | "service" | "team") | No | The type of resource to filter upon. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Send MCP request **Slug:** `PAGERDUTY_SEND_MCP_REQUEST` Tool to send JSON-RPC requests to PagerDuty's Model Context Protocol (MCP) endpoint. Use when you need to interact with MCP servers for tool execution, resource management, or prompt operations. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | A unique identifier for this request. Can be an integer or string. | | `method` | string | Yes | The method to be invoked on the MCP server. Common methods include 'initialize', 'tools/list', 'tools/call', 'resources/list', 'prompts/list', etc. | | `params` | object | No | The parameters to be passed to the method. Structure depends on the method being called. For 'initialize', include protocolVersion, capabilities, and clientInfo. For 'tools/call', include tool name and arguments. | | `jsonrpc` | string ("2.0") | No | The JSON-RPC version, must be "2.0". | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Send responder requests for incidents **Slug:** `PAGERDUTY_SEND_RESPONDER_REQUESTS_FOR_INCIDENTS` Send responder requests to users or escalation policies for a PagerDuty incident. Use this action to request additional help for an ongoing incident by notifying specific users or escalation policies. This is useful when an incident requires more expertise, resources, or urgent attention beyond the currently assigned team. The responder request includes a message explaining why help is needed and allows you to target multiple responders at once (up to 500 unique responders and 1000 responder requests per incident). Note: This action requires a PagerDuty plan that includes the Add Responders feature. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident to request responders for. | | `message` | string | Yes | A message to send with the responder request explaining why help is needed. | | `requester_id` | string | Yes | The ID of the user making the responder request. Must be a valid PagerDuty user ID. | | `responder_request_targets` | array | Yes | An array of responder target objects. Each target must have "id" (the user or escalation policy ID) and "type" (either "user_reference" or "escalation_policy_reference"). Example: [{"id": "PXYZ123", "type": "user_reference"}] | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Set business service impact status **Slug:** `PAGERDUTY_SET_BUSINESS_SERVICE_IMPACT_STATUS` This endpoint updates the impact status of a specific incident on a particular business service in PagerDuty. It allows you to either set a business service as impacted by an incident or remove the impact, which in turn affects the propagation of the impact to other supported services. Use this endpoint when you need to manually adjust the impact of an incident on your business services, either to escalate its importance or to mark it as resolved for specific services. This tool is particularly useful for managing the scope and severity of incidents across your organization's service hierarchy. Note that updating the impact status will have cascading effects on services supported by the targeted business service. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `relation` | string ("impacted" | "not_impacted") | Yes | Relation | | `business_service_id` | string | Yes | The business service ID. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Set global priority threshold **Slug:** `PAGERDUTY_SET_GLOBAL_PRIORITY_THRESHOLD` Sets the global Priority Threshold for Business Services in PagerDuty, determining which incidents can impact these services based on their priority level. This endpoint allows you to configure the minimum incident priority required to affect Business Services by specifying an 'id' and 'order' for the threshold. Use this when you need to adjust how incidents of different priorities impact your Business Services. Note that incidents below this threshold won't impact Business Services unless manually added using a separate endpoint. This configuration is crucial for managing service impacts and prioritizing incident responses effectively. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `global__threshold__id` | string | No | Id | | `global__threshold__order` | integer | No | Order | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Snooze incident by duration **Slug:** `PAGERDUTY_SNOOZE_INCIDENT_BY_DURATION` Snooze an acknowledged incident in PagerDuty for a specified duration. This temporarily suppresses notifications for the incident, automatically returning it to the "triggered" state when the snooze period expires. The incident must be in "acknowledged" status before snoozing. **Use Cases:** - Managing alert fatigue during investigation - Waiting for upstream dependencies to recover - Delaying notifications during maintenance windows - Handling known false positives that require time to verify **Important Notes:** - Snoozing does NOT resolve the incident - it only delays notifications - The incident will automatically re-trigger after the snooze duration - Reassigning a snoozed incident cancels the snooze timer - Maximum snooze duration is 1 week (604,800 seconds) **Prerequisites:** - Incident must be in "acknowledged" status (use update incident action first if needed) - User must have permission to modify the incident #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The incident ID to snooze. The incident must be in 'acknowledged' status. Example: 'Q1LM34T0WT52EL'. You can get incident IDs from the list incidents endpoint. | | `content` | string | No | A note or reason describing why the incident is being snoozed. This helps track the context for the snooze action and appears in the incident timeline. Example: "Snoozing while waiting for upstream service recovery" | | `duration` | integer | Yes | The number of seconds to snooze the incident for. After this duration elapses, the incident will automatically return to the "triggered" state. Common values: 3600 (1 hour), 7200 (2 hours), 14400 (4 hours), 28800 (8 hours), 86400 (24 hours). Maximum: 604800 (1 week). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Subscribe entities to business services **Slug:** `PAGERDUTY_SUBSCRIBE_ENTITIES_TO_BUSINESS_SERVICES` This endpoint allows you to subscribe users or teams to a specific business service in PagerDuty. It enables you to add multiple subscribers in a single request, streamlining the process of setting up notification recipients for critical incidents. Use this endpoint when you need to configure who receives alerts and updates for a particular business service. The endpoint is particularly useful for initial setup or bulk updates to subscriber lists. Note that this operation adds new subscribers but does not remove existing ones; to remove subscribers, you would need to use a separate endpoint. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `subscribers` | array | Yes | Subscribers | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Subscribe entities to incident status updates **Slug:** `PAGERDUTY_SUBSCRIBE_ENTITIES_TO_INCIDENT_STATUS_UPDATES` Subscribes specified users or teams to receive status updates for a particular incident in PagerDuty. This endpoint allows you to add multiple subscribers at once, ensuring that relevant parties are kept informed about the incident's progress. It's particularly useful when you need to involve additional stakeholders or support teams during an ongoing incident. The endpoint requires the incident ID and a list of subscribers, each defined by their unique ID and type (user or team). Use this when you want to expand the notification list for critical updates about an incident, but be mindful not to oversubscribe, as it may lead to notification fatigue. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the incident to subscribe entities to (e.g., 'Q1LM34T0WT52EL') | | `subscribers` | array | Yes | List of users or teams to subscribe to this incident's status updates. Each subscriber must have a subscriber_id and subscriber_type. You can subscribe multiple entities in a single request. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Subscribe to user notifications **Slug:** `PAGERDUTY_SUBSCRIBE_TO_USER_NOTIFICATIONS` Creates notification subscriptions for a specific user in PagerDuty. This endpoint allows you to subscribe a user to multiple incidents or business services in a single API call. It's particularly useful for setting up customized notification preferences for users, ensuring they receive alerts for specific entities they need to monitor. The endpoint supports bulk subscription, allowing you to subscribe a user to multiple entities simultaneously, improving efficiency in managing user notifications. Note that this endpoint only creates subscriptions and does not modify or delete existing ones. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user to create notification subscriptions for | | `subscribables` | array | Yes | List of entities (incidents or business services) to subscribe the user to. Supports bulk subscription by including multiple items in the list | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Unsubscribe business service entity **Slug:** `PAGERDUTY_UNSUBSCRIBE_BUSINESS_SERVICE_ENTITY` This endpoint unsubscribes specified users or teams from receiving notifications for a particular business service in PagerDuty. It allows bulk unsubscription of multiple entities in a single API call. The endpoint should be used when you need to remove one or more users or teams from the notification list of a specific business service, such as when reorganizing team responsibilities or updating notification preferences. It's important to note that this action is immediate and irreversible, so care should be taken to ensure the correct entities are being unsubscribed. The endpoint doesn't provide a way to confirm or preview the changes before they're applied, so it's recommended to double-check the subscriber information before making the API call. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the business service from which to unsubscribe entities | | `subscribers` | array | Yes | List of users or teams to unsubscribe from this business service. Each entry must include a subscriber_id and subscriber_type | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Unsubscribe from incident status updates **Slug:** `PAGERDUTY_UNSUBSCRIBE_FROM_INCIDENT_STATUS_UPDATES` Unsubscribes specified users or teams from receiving status updates for a particular incident in PagerDuty. This endpoint is used when certain entities no longer need to be notified about changes to an incident's status. It allows for bulk unsubscription of multiple users and/or teams in a single API call. The endpoint requires the incident ID in the URL path and a list of subscribers to unsubscribe in the request body. It's important to note that this action cannot be undone through the API, and re-subscription would require a separate API call if needed later. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident from which to unsubscribe entities. This is the unique incident identifier (e.g., 'Q1LM34T0WT52EL'). | | `subscribers` | array | Yes | List of users and/or teams to unsubscribe from incident status updates. Each subscriber requires a subscriber_id and subscriber_type. Can unsubscribe multiple entities in a single request. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Unsubscribe team notification subscriptions **Slug:** `PAGERDUTY_UNSUBSCRIBE_TEAM_NOTIFICATION_SUBSCRIPTIONS` Unsubscribes a team from notifications for specific incidents or business services in PagerDuty. This endpoint is used to stop a team from receiving alerts and updates about particular entities. It's particularly useful for managing notification overload or when a team is no longer responsible for certain incidents or services. The endpoint requires a list of subscribables (entities to unsubscribe from), each identified by a unique ID and type. At least one subscribable must be provided, and all items in the list must be unique. This operation cannot be undone through this endpoint, so use it cautiously. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the team to unsubscribe from notification subscriptions. This is a PagerDuty team ID (e.g., 'P123ABC'). | | `subscribables` | array | Yes | List of entities (incidents or business services) that the team should be unsubscribed from. Each item must specify a subscribable_id and subscribable_type. At least one subscribable is required. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Unsubscribe user notification subscriptions **Slug:** `PAGERDUTY_UNSUBSCRIBE_USER_NOTIFICATION_SUBSCRIPTIONS` This endpoint allows unsubscribing a user from notifications for specific incidents or business services in PagerDuty. It's used to modify a user's notification preferences, removing them from receiving updates about particular entities. The endpoint accepts a list of subscribable entities, each identified by an ID and type, and removes the user's subscription to these entities. This is particularly useful for managing notification overload or when a user no longer needs updates about certain incidents or services. The endpoint requires at least one subscribable entity and ensures that all entries in the request are unique. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user to unsubscribe from notifications | | `subscribables` | array | Yes | List of entities (incidents or business services) to unsubscribe the user from. Each entry must have a subscribable_id and subscribable_type | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update a custom field for an incident type **Slug:** `PAGERDUTY_UPDATE_A_CUSTOM_FIELD_FOR_AN_INCIDENT_TYPE` Update a custom field for an incident type. Custom Fields (CF) are a feature which will allow customers to extend Incidents with their own custom data, to provide additional context and support features such as customized filtering, search and analytics. Custom Fields can be applied to different incident types. > ### Early Access > This endpoint is in Early Access and may change at any time. You must pass in the X-EARLY-ACCESS header to access it. Scoped OAuth requires: `custom_fields.write` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field_id` | string | Yes | The unique identifier of the custom field to update. You can get this from the LIST_INCIDENT_TYPE_CUSTOM_FIELDS action. | | `field__enabled` | boolean | No | Optional. Whether the custom field is enabled and available for use on incidents. Set to true to enable or false to disable. | | `type_id_or_name` | string | Yes | The unique identifier (ID) or name of the Incident Type to update. You can get this from the LIST_INCIDENT_TYPES action. | | `field__description` | string | No | Optional. A detailed description explaining the purpose and usage of this custom field for team members. | | `field__display__name` | string | No | Optional. The human-readable display name for the custom field (e.g., 'Severity Level', 'Customer Impact'). | | `field__default__value` | string | No | Optional. The default value to assign to this custom field when creating new incidents of this type. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update add on by id **Slug:** `PAGERDUTY_UPDATE_ADD_ON_BY_ID` Updates an existing Add-on in PagerDuty with new properties. This endpoint allows you to modify the type, name, and source URL of a specific Add-on identified by its unique ID. It's used when you need to change the configuration or appearance of an Add-on that's already integrated into your PagerDuty instance. The endpoint updates only the mutable fields and returns the full updated Add-on object, including read-only fields. Note that this operation cannot modify the Add-on's ID or other system-generated fields like 'summary', 'self', or 'html_url'. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the add-on to update. This is a unique identifier for a specific add-on installed on your PagerDuty account. | | `addon` | object | Yes | The addon object containing the fields to update. Can include 'name' (string, the display name), 'src' (string, the HTTPS source URL), and 'type' (string, either 'full_page_addon' or 'incident_show_addon'). Only the fields you include will be updated. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update alert grouping settings byid **Slug:** `PAGERDUTY_UPDATE_ALERT_GROUPING_SETTINGS_BY_ID` Update an existing Alert Grouping Setting in PagerDuty by its ID. Alert Grouping Settings control how alerts are automatically grouped into incidents, reducing noise and streamlining incident management. This endpoint allows you to modify: - Grouping type (time, intelligent, content_based, or content_based_intelligent) - Configuration parameters (time windows, field matching rules) - Associated services - Display name and description **Important Notes:** - This is a PUT request requiring the complete alert_grouping_setting object - Some grouping types (e.g., intelligent) may require specific PagerDuty plan features - The 'content_based_intelligent' type only supports one service per setting - Time windows must be 300-3600 seconds (or 86400 for content_based only) - Only include writable fields; omit read-only fields (id, created_at, updated_at) **Use this when:** You need to change how alerts are grouped for specific services, adjust time windows, or modify field-based grouping rules. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `alert__grouping__setting__id` | string | No | DEPRECATED: The unique identifier of the alert grouping setting. This is a read-only field auto-generated by PagerDuty. Do not include this field in update requests as it will be ignored. | | `alert__grouping__setting__name` | string | No | An optional short-form string that provides succinct information about an AlertGroupingSetting object suitable for primary labeling of the entity. It is not intended to be an identifier. | | `alert__grouping__setting__type` | string ("content_based" | "content_based_intelligent" | "intelligent" | "time") | No | The type of alert grouping to use. Options are: 'time' (groups alerts within a time window), 'intelligent' (uses ML to group related alerts), 'content_based' (groups based on matching field values), or 'content_based_intelligent' (combines content matching with intelligent grouping). The type determines which config parameters are required. | | `alert__grouping__setting__config` | object | No | Configuration object for the alert grouping. Structure depends on the 'type' field. For 'time' grouping: {'timeout': }. For 'content_based' or 'content_based_intelligent': {'fields': [], 'time_window': } where fields is required. For 'intelligent': {'time_window': } or empty. Time window values must be between 300-3600 seconds, or 86400 for content_based only. Set to null/omit time_window to use the recommended default. | | `alert__grouping__setting__services` | array | No | Array of service references that this alert grouping setting applies to. Each service should be a dict with 'id' (required) and optionally 'type' fields. Example: [{'id': 'PXXXXXX', 'type': 'service_reference'}]. Note: 'content_based_intelligent' grouping type only allows one service in the array, while other types support multiple services. | | `alert__grouping__setting__created__at` | string | No | DEPRECATED: The ISO8601 date/time when the AlertGroupingSetting was created. This is a read-only field auto-generated by PagerDuty. Do not include this field in update requests. | | `alert__grouping__setting__description` | string | No | An optional description in string that provides more information about an AlertGroupingSetting object. | | `alert__grouping__setting__updated__at` | string | No | DEPRECATED: The ISO8601 date/time when the AlertGroupingSetting was last updated. This is a read-only field auto-generated by PagerDuty. Do not include this field in update requests. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update alert in incident **Slug:** `PAGERDUTY_UPDATE_ALERT_IN_INCIDENT` Updates the status of a specific alert within an incident in PagerDuty. This endpoint allows you to modify an alert's status, primarily to mark it as resolved. It's crucial for managing the lifecycle of alerts and incidents in PagerDuty's incident management system. Use this when you need to programmatically update the state of an alert, typically as part of an automated incident resolution process or when integrating external systems with PagerDuty. Note that while the endpoint accepts various fields in the request body, most are read-only, with the 'status' field being the primary modifiable attribute. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident containing the alert to update. | | `alert_id` | string | Yes | The ID of the alert to update within the incident. | | `alert__status` | string ("resolved" | "triggered") | No | The new status for the alert. Options: 'resolved' to resolve the alert, or 'triggered' to re-trigger it. This is the primary modifiable field. | | `alert__incident__id` | string | Yes | The ID of the incident to associate this alert with. This is required when updating an alert and should match the incident ID in the path parameter. | | `alert__incident__type` | string ("incident_reference") | No | The type of the incident reference. Must be 'incident_reference'. Defaults to 'incident_reference'. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update an incident type **Slug:** `PAGERDUTY_UPDATE_AN_INCIDENT_TYPE` Update an Incident Type. Incident Types are a feature which will allow customers to categorize incidents, such as a security incident, a major incident, or a fraud incident. > ### Early Access > This endpoint is in Early Access and may change at any time. You must pass in the X-EARLY-ACCESS header to access it. For more information see the [API Concepts Document](../../api-reference/ZG9jOjI3NDc5Nzc-api-concepts#incident) Scoped OAuth requires: `incident_types.write` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `type_id_or_name` | string | Yes | The ID or name of the Incident Type. | | `incident__type__enabled` | boolean | No | Whether the Incident Type is enabled. Defaults to true if not provided. | | `incident__type__description` | string | No | The description of the Incident Type. | | `incident__type__display__name` | string | No | The display name of the Incident Type. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update incident workflow trigger **Slug:** `PAGERDUTY_UPDATE_A_TRIGGER` Updates an existing incident workflow trigger in PagerDuty. Triggers define when and how incident workflows are activated - either automatically based on conditions, manually by responders, or for specific incident types. You can update the trigger type, workflow association, PCL conditions, service scope, and permissions. Conditional triggers require a PCL condition string (e.g., "incident.priority matches 'P1'"). Specify either a services list or subscribed_to_all_services (not both). Common use cases: - Change which workflow a trigger executes - Update the conditions for a conditional trigger - Modify service associations - Update permissions for manual triggers - Switch trigger type (e.g., from manual to conditional) Requires the `incident_workflows.write` OAuth scope. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident workflow trigger to update | | `trigger` | object | Yes | The trigger configuration object with fields to update | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update automation runner info **Slug:** `PAGERDUTY_UPDATE_AUTOMATION_RUNNER_INFO` This endpoint allows you to update an existing Automation Action Runner in PagerDuty. It is used to modify the properties of a runner, such as its name, description, and, for runbook runners, the runbook server connection details. The endpoint supports updating both sidecar and runbook type runners, distinguished by the 'runner_type' discriminator. Use this endpoint when you need to change the configuration of an existing runner, such as updating its name for better identification or modifying the runbook server details. Note that while you can update most properties, you cannot change a runner's type (e.g., from sidecar to runbook) using this endpoint. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the automation runner to update (e.g., 'P1RUNNER', 'PRUNNER123'). This ID is returned when creating a runner or can be obtained by listing all runners. | | `runner` | string | Yes | Runner update object containing the fields to modify. All fields are optional - only include the fields you want to update. Available fields: name (runner display name), description (runner description), runbook_base_uri (Runbook server URL for runbook type), runbook_api_key (authentication token for runbook type). Note: You cannot change the runner's type (e.g., from sidecar to runbook). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update business service by id **Slug:** `PAGERDUTY_UPDATE_BUSINESS_SERVICE_BY_ID` This endpoint allows you to update an existing Business Service in PagerDuty. It is used to modify the details of a specific service, such as its name, description, point of contact, or the team responsible for it. This is particularly useful when service information changes or when reassigning responsibilities within your organization. The endpoint requires the unique identifier of the Business Service and accepts a JSON object with the updated information. It's important to note that you only need to include the fields you want to update; omitted fields will retain their current values. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the Business Service to update (e.g., 'P5Z4SLO'). This is required and identifies which business service will be modified. | | `business__service__name` | string | No | The new name for the Business Service. This is a human-readable identifier for the service (max 100 characters). Only include this parameter if you want to update the name. | | `business__service__team__id` | string | No | The ID of the PagerDuty team that should own this Business Service (e.g., 'P4SI6QB'). Use this to reassign the business service to a different team. Only include this parameter if you want to change team ownership. Note: This requires a PagerDuty subscription that includes Teams functionality. | | `business__service__description` | string | No | The new description for the Business Service. This provides context about what the service does and its purpose. Only include this parameter if you want to update the description. Set to empty string to clear the description. | | `business__service__point__of__contact` | string | No | The new point of contact for the Business Service. This can be an email address, phone number, person's name, or any other contact information for the person or team responsible for this service. Only include this parameter if you want to update the point of contact. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update change event by ID **Slug:** `PAGERDUTY_UPDATE_CHANGE_EVENT_BY_ID` Update an existing change event in PagerDuty by its unique ID. Modify summary, source, custom_details, or links for change events tracking deployments, configuration changes, or system modifications. **Updatable fields:** summary, source, custom_details, links (each replaces existing value) **Read-only fields:** id, type, timestamp, service, integration **Requirements:** PagerDuty AIOps add-on, change_events:write scope Use to correct typos, update metadata, add context, or replace documentation links. All updates replace existing field values entirely (no merging). #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the change event to update. This is the change event ID returned when creating or listing change events. | | `change_event` | object | Yes | The change event object containing the fields to update. Only include fields you want to modify. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update Custom Field Display Name **Slug:** `PAGERDUTY_UPDATE_CUSTOM_FIELD_DISPLAY_NAME` Updates an existing custom field for incidents in PagerDuty. This endpoint allows you to modify the display name, description, and default value of a custom field identified by its unique field_id. Use this action when you need to change the properties of a custom field, such as renaming it, updating its description, or setting a new default value. **Prerequisites:** 1. A valid custom field ID (use PAGERDUTY_RETRIEVE_INCIDENT_CUSTOM_FIELDS to list available fields) 2. At least one field property to update (display_name, description, or default_value) **Important Notes:** - Updating a custom field affects all incidents that use this field - The display_name must be unique across the account - Use this endpoint cautiously in production environments - Requires the `custom_fields.write` OAuth scope #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field_id` | string | Yes | The unique identifier of the custom field to update. Use PAGERDUTY_RETRIEVE_INCIDENT_CUSTOM_FIELDS to list available custom field IDs. | | `field__description` | string | No | A description of the data this field contains and its purpose. If not provided, the existing description is preserved. | | `field__display__name` | string | No | The human-readable name of the field to display in the PagerDuty UI. This must be unique across the account. If not provided, the existing display name is preserved. | | `field__default__value` | object | No | The default value to be assigned to this custom field when new incidents are created. The structure of this value depends on the field's data type and configuration. If not provided, the existing default value is preserved. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update custom field option **Slug:** `PAGERDUTY_UPDATE_CUSTOM_FIELD_OPTION` Updates a field option for a custom field on an incident type in PagerDuty. Field options represent the selectable values for multi-value or dropdown custom fields. Use this action to modify the display value or data type of an existing option. **Prerequisites:** 1. A valid incident type ID or name (use PAGERDUTY_LIST_INCIDENT_TYPES) 2. A valid custom field ID for that incident type (use PAGERDUTY_LIST_INCIDENT_TYPE_CUSTOM_FIELDS) 3. An existing field option ID to update (use PAGERDUTY_LIST_FIELD_OPTIONS_ON_A_CUSTOM_FIELD) 4. The custom field should be of type 'multi_value' or 'multi_value_fixed' to support options **Common use cases:** - Renaming field options to match updated terminology (e.g., "Critical" → "Urgent") - Correcting typos in existing field option values - Adjusting options to better reflect current operational needs **Note:** This is an Early Access endpoint requiring the `custom_fields.write` OAuth scope. The X-EARLY-ACCESS header with value 'analytics-v2' is automatically included. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `field_id` | string | Yes | The ID of the custom field. Use PAGERDUTY_LIST_INCIDENT_TYPE_CUSTOM_FIELDS to get valid field IDs for an incident type. | | `field_option_id` | string | Yes | The ID of the field option to update. Use PAGERDUTY_LIST_FIELD_OPTIONS_ON_A_CUSTOM_FIELD to get available field option IDs. | | `type_id_or_name` | string | Yes | The ID or name of the Incident Type. Use PAGERDUTY_LIST_INCIDENT_TYPES to find valid incident type IDs or names. | | `field__option__data__value` | string | No | The updated value for the field option. This is the text that users will see when selecting this option. If not provided, the existing value is preserved. | | `field__option__data__data__type` | string | No | The data type of the field option value. Typically 'string' for text values. If not provided, the existing data type is preserved. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update escalation policy by id **Slug:** `PAGERDUTY_UPDATE_ESCALATION_POLICY_BY_ID` Updates an existing escalation policy in PagerDuty with new settings and rules. This endpoint allows you to modify various aspects of an escalation policy, including its name, description, escalation rules, associated services, and team. It's used when you need to change how incidents are escalated and handled within your organization. The updated policy details are provided in the request body, and the policy to be updated is identified by its ID in the URL path. This tool is essential for maintaining and adjusting incident response workflows in PagerDuty to ensure optimal team responsiveness and incident management. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the escalation policy to update | | `escalation_policy` | object | Yes | The escalation policy object with fields to update. At least one field must be provided. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update escalation policy for team **Slug:** `PAGERDUTY_UPDATE_ESCALATION_POLICY_FOR_TEAM` Associates an escalation policy with a team in PagerDuty. This creates or updates the link between a team and an escalation policy, enabling the team to use that policy for incident management. When an escalation policy is added to a team, the users, schedules, and services associated with that policy are also added to the team. Note: This does NOT modify the escalation policy's configuration itself (like notification rules or escalation steps). To update the policy configuration, use the update_escalation_policy_by_id action instead. This action only manages the team-policy association. Important: An escalation policy can only be associated with one team at a time. The account must have the Teams feature enabled (typically requires a paid plan). #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the team to associate with the escalation policy. | | `escalation_policy_id` | string | Yes | The ID of the escalation policy to add/associate to the team. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update event orchestration by id **Slug:** `PAGERDUTY_UPDATE_EVENT_ORCHESTRATION_BY_ID` Updates an existing Event Orchestration in PagerDuty. This endpoint allows you to modify the name, description, and team ownership of a specific Orchestration identified by its ID. It's used to refine and adjust your incident management workflow by updating the configuration of how events are processed and routed. This tool is particularly useful when you need to change the purpose, ownership, or details of an Orchestration without creating a new one. Note that certain properties like integrations, routing information, and timestamps are read-only and cannot be modified through this endpoint. Use this when you need to update an Orchestration's metadata or reassign it to a different team. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | | `orchestration__id` | string | No | ID of the Orchestration. | | `orchestration__name` | string | No | Name of the Orchestration. | | `orchestration__self` | string | No | The API show URL at which the object is accessible | | `orchestration__routes` | integer | No | Number of different Service Orchestration being routed to | | `orchestration__version` | string | No | Version of the Orchestration. | | `orchestration__team__id` | string | No | Id | | `orchestration__team__self` | string | No | The API show URL at which the object is accessible | | `orchestration__team__type` | string | No | A string that determines the schema of the object | | `orchestration__created__at` | string | No | The date the Orchestration was created at. | | `orchestration__description` | string | No | A description of this Orchestration"s purpose. | | `orchestration__updated__at` | string | No | The date the Orchestration was last updated. | | `orchestration__integrations` | array | No | Integrations | | `orchestration__created__by__id` | string | No | Id | | `orchestration__updated__by__id` | string | No | Id | | `orchestration__created__by__self` | string | No | The API show URL at which the object is accessible | | `orchestration__created__by__type` | string | No | A string that determines the schema of the object | | `orchestration__updated__by__self` | string | No | The API show URL at which the object is accessible | | `orchestration__updated__by__type` | string | No | A string that determines the schema of the object | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update Event Orchestration Cache Variable **Slug:** `PAGERDUTY_UPDATE_EVENT_ORCHESTRATION_CACHE_VARIABLE` This endpoint updates a cache variable associated with a specific service in PagerDuty's event orchestrations. It allows you to modify the cache variable's name, configuration, conditions, and disabled state. Use this endpoint when you need to change how a cache variable behaves, such as updating its value extraction method or trigger event count settings. The endpoint is particularly useful for fine-tuning event processing rules and maintaining dynamic incident management workflows. Note that some fields like ID, creation date, and last update information are read-only and cannot be modified through this endpoint. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `service_id` | string | Yes | The service ID | | `cache_variable_id` | string | Yes | The ID of a Cache Variable. | | `cache__variable__id` | string | No | Id | | `cache__variable__name` | string | No | The name of the Cache Variable | | `cache__variable__disabled` | boolean | No | Indicates whether the Cache Variable is disabled and would therefore not be evaluated. | | `cache__variable__conditions` | array | No | Each of these conditions is evaluated to check if an event matches this rule. The rule is considered a match if **any** of these conditions match. | | `cache__variable__created__at` | string | No | The date/time the object was created. | | `cache__variable__updated__at` | string | No | The date/time the object was last updated. | | `cache__variable__configuration` | object | No | Configuration | | `cache__variable__created__by__id` | string | No | Id | | `cache__variable__updated__by__id` | string | No | Id | | `cache__variable__created__by__self` | string | No | The API show URL at which the object is accessible | | `cache__variable__created__by__type` | string | No | A string that determines the schema of the object. This must be the standard name for the entity, suffixed by `_reference` if the object is a reference. | | `cache__variable__updated__by__self` | string | No | The API show URL at which the object is accessible | | `cache__variable__updated__by__type` | string | No | A string that determines the schema of the object. This must be the standard name for the entity, suffixed by `_reference` if the object is a reference. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update event rule by id **Slug:** `PAGERDUTY_UPDATE_EVENT_RULE_BY_ID` This endpoint allows you to update an existing Event Rule within a specified Ruleset in PagerDuty. Event Rules define conditions for matching events and actions to take when those conditions are met. You can modify various aspects of the rule, including its active status, matching conditions, time frames, variables, position in the ruleset, and associated actions. This endpoint is particularly useful for fine-tuning your incident management workflow, adjusting how events are processed, and controlling alert behavior. It's important to note that changes made through this endpoint will immediately affect how incoming events are handled, so careful consideration should be given to the potential impact on your alerting system. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the ruleset that contains the event rule. | | `rule` | object | No | The event rule configuration object to update. This object defines how incoming events should be processed. It can include: 'conditions' (matching criteria with operator and subconditions), 'actions' (what to do when conditions match - route, annotate, severity, priority, suppress, extract, etc.), 'position' (integer order in ruleset), 'disabled' (boolean to disable rule), 'time_frame' (scheduling with active_between or scheduled_weekly), and 'variables' (data extractions from event payload). Example: {"conditions": {"operator": "and", "subconditions": [{"operator": "contains", "parameter": {"path": "summary", "value": "database"}}]}, "actions": {"route": {"value": "SERVICE_ID"}, "severity": {"value": "warning"}}, "position": 1, "disabled": false}. Fields not provided will remain unchanged. | | `rule_id` | string | Yes | The ID of the Event Rule to update. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update event rule for service **Slug:** `PAGERDUTY_UPDATE_EVENT_RULE_FOR_SERVICE` This endpoint allows you to update an existing Event Rule for a specific service in PagerDuty. Event Rules are used to define how incoming events should be processed, including conditions for matching events and actions to take when a match occurs. You can modify various aspects of the rule, such as its conditions, time-based restrictions, variables for extraction, and actions to perform on matching events. This endpoint is particularly useful for fine-tuning event management processes, adjusting rule priorities, or temporarily disabling rules without removing them entirely. It provides granular control over event handling, allowing for sophisticated automation and incident management workflows. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the service to update the event rule for. | | `rule` | object | No | The updated event rule configuration object. Can include 'actions' (operations like suppress, severity, priority, annotate), 'conditions' (with operator and subconditions for matching events), 'time_frame' (scheduling when rule is active), 'variables' (for extracting event data), 'position' (for rule ordering), and 'disabled' (to disable the rule). Only include fields you want to update. Example: {'actions': {'severity': {'value': 'warning'}}, 'disabled': false} | | `rule_id` | string | Yes | The ID of the event rule to update. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update extension by id **Slug:** `PAGERDUTY_UPDATE_EXTENSION_BY_ID` Updates an existing extension in PagerDuty. This endpoint allows you to modify the configuration of a previously created extension, such as a webhook or custom integration. You can update properties like the extension's name, endpoint URL, associated objects, and custom configuration. This is useful for maintaining and adjusting integrations as your operational needs change. The endpoint requires the extension's ID in the URL path and accepts a JSON payload with the updated extension details. It's important to note that some fields, like the extension's ID and type, are read-only and cannot be modified through this endpoint. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the extension to update. | | `extension` | object | Yes | The extension object with updated fields. This is a PUT request, so you should provide all core fields: 'name' (extension name), 'endpoint_url' (webhook URL), 'extension_schema' (object with 'id' and 'type' fields), and 'extension_objects' (array of service references, each with 'id' and 'type' fields). Optional fields include 'config' (JSON object for extension configuration) and 'type' (usually 'webhook'). The API uses PUT semantics, so provide complete data for the extension. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update the global orchestration for an event orchestration **Slug:** `PAGERDUTY_UPDATE_GLOBAL_ORCHESTRATION` Update the Global Orchestration configuration for an Event Orchestration. This action allows you to update global-level event routing rules and processing logic that apply to all events sent to an orchestration before they reach service-specific rules. The orchestration_path must include: - 'sets': A list of rule sets (at least one with id='start'). Each set contains: - 'id': Unique identifier for the set (first set must be 'start') - 'rules': List of rules, each with optional 'conditions' and 'actions' - 'catch_all': Fallback actions object applied when no rules match (must have 'actions' key) Rule actions can include: route_to, severity, priority, annotate, suppress, suspend, etc. Use the get_event_orchestration_global action first to retrieve the current configuration, then modify and send it back to update. For more information see the [API Concepts Document](../../api-reference/ZG9jOjI3NDc5Nzc-api-concepts#event-orchestrations) Scoped OAuth requires: `event_orchestrations.write` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | | `orchestration_path` | object | Yes | The global orchestration path configuration containing sets of rules and catch-all actions. Must include: 'sets' (a list of rule sets, with at least one set with id='start'), and 'catch_all' (fallback actions object). Each set contains an 'id' and a 'rules' list. Rules can contain 'conditions' and 'actions' (such as route_to, severity, annotate, etc.). The catch_all contains an 'actions' object with fallback processing rules. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update incident alerts **Slug:** `PAGERDUTY_UPDATE_INCIDENT_ALERTS` This endpoint allows you to update the status of multiple alerts associated with a specific incident in PagerDuty. It is particularly useful for bulk operations when you need to resolve or update the status of several alerts simultaneously within the context of a single incident. The endpoint accepts an array of alert objects, each containing the necessary information for the update. It's important to note that this endpoint modifies existing alerts and cannot be used to create new alerts or incidents. Use this when you need to efficiently manage and update the state of multiple alerts tied to an ongoing incident. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `limit` | integer | No | The number of results per page. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `alerts` | array | Yes | An array of alerts to update. Each alert object must include the alert ID and the desired status ('resolved' or 'triggered'). You can also optionally specify the incident reference. | | `offset` | integer | No | Offset to start pagination search results. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update incident by id **Slug:** `PAGERDUTY_UPDATE_INCIDENT_BY_ID` The UpdateIncident endpoint allows you to modify various attributes of an existing incident in PagerDuty's incident management system. This PUT operation enables users to update incident status, priority, assignments, escalation levels, and other key properties. It's particularly useful for reflecting the current state of an incident, reassigning responsibilities, or adjusting the incident's urgency and escalation path. The endpoint should be used when there are significant changes to an incident that need to be reflected in the system, such as acknowledging the incident, marking it as resolved, or changing its priority. It's important to note that this endpoint updates an existing incident and does not create new incidents. Care should be taken when modifying critical fields like status or escalation policy, as these changes can significantly impact the incident management workflow. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `incident__type` | string ("incident" | "incident_reference") | No | The incident type. | | `incident__title` | string | No | The new title of the incident. | | `incident__status` | string ("resolved" | "acknowledged") | No | The new status of the incident. | | `incident__urgency` | string ("high" | "low") | No | The urgency of the incident. | | `incident__resolution` | string | No | The resolution for this incident if status is set to resolved. | | `incident__assignments` | array | No | Assign the incident to these assignees. | | `incident__escalation__level` | integer | No | Escalate the incident to this level in the escalation policy. | | `incident__incident__type__id` | string | No | Id | | `incident__incident__type__name` | string | No | The name of the Incident Type. | | `incident__conference__bridge__conference__url` | string | No | An URL for the conference bridge. This could be a link to a web conference or Slack channel. | | `incident__conference__bridge__conference__number` | string | No | The phone number of the conference call for the conference bridge. Phone numbers should be formatted like +1 415-555-1212,,,,1234#, where a comma (,) represents a one-second wait and pound (#) completes access code input. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update incident custom field values **Slug:** `PAGERDUTY_UPDATE_INCIDENT_CUSTOM_FIELD_VALUES` Updates custom field values for a specific incident in PagerDuty. Custom fields enrich incidents with metadata like environment, severity, version info, runbook links, etc. Supports string, number, boolean, URL, datetime, and select field types. Operation is idempotent and overwrites existing values for specified fields. Requires incident:write scope and pre-configured custom fields (typically on Enterprise plans). Use PAGERDUTY_RETRIEVE_INCIDENT_CUSTOM_FIELDS to get available field IDs before updating. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident to update custom field values for. Format: Starts with "P" followed by alphanumeric characters (e.g., "PMN3VMG", "P1OGMH6"). Use PAGERDUTY_FETCH_INCIDENT_LIST or PAGERDUTY_CREATE_INCIDENT_RECORD to get incident IDs. | | `custom_fields` | array | Yes | Array of custom field value updates. Each element must contain: - "id" (string, required): The ID of the custom field to update - "value" (required): The new value for the field. Type depends on field configuration (string, integer, boolean, array, datetime, url, etc.). Example: [{"id": "FIELD_ID_1", "value": "Production"}, {"id": "FIELD_ID_2", "value": 42}] To get available custom field IDs, use the PAGERDUTY_RETRIEVE_INCIDENT_CUSTOM_FIELDS action. Note: This feature requires custom fields to be configured and may require specific PagerDuty plan tier and permissions. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update incident details **Slug:** `PAGERDUTY_UPDATE_INCIDENT_DETAILS` This endpoint allows for bulk updating of multiple PagerDuty incidents in a single API call. It can be used to modify various attributes of incidents such as status, priority, assignments, and more. This is particularly useful for automating incident management processes, batch resolving or acknowledging incidents, or updating incident details en masse. The endpoint accepts an array of incident objects, each containing the necessary updates, allowing for efficient management of multiple incidents simultaneously. It's important to note that while many fields are optional, each incident object must include the 'id' and 'type' fields for proper identification and processing. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `limit` | integer | No | The number of results per page. | | `total` | boolean | No | By default the `total` field in pagination responses is set to `null` to provide the fastest possible response times. Set `total` to `true` for this field to be populated. See our [Pagination Docs](https://developer.pagerduty.com/docs/rest-api-v2/pagination/) for more information. | | `offset` | integer | No | Offset to start pagination search results. | | `incidents` | array | Yes | An array of incident objects to update in bulk. Each incident object must include: (1) 'id' (required): The incident ID to update, (2) 'type' (required): Must be 'incident' or 'incident_reference', and (3) optional fields to update such as 'status' (triggered/acknowledged/resolved), 'title', 'urgency' (high/low), 'priority', 'resolution', 'escalation_level', 'assignments', 'incident_type', 'conference_bridge', etc. Example: [{'id': 'ABC123', 'type': 'incident', 'status': 'resolved'}] | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update incident workflow **Slug:** `PAGERDUTY_UPDATE_INCIDENT_WORKFLOW` This endpoint updates an existing Incident Workflow in PagerDuty by its unique identifier. It allows you to modify various aspects of the workflow, including its name, description, associated team, and the sequence of steps to be executed during an incident. The primary use case is to refine or adjust incident response processes by altering the workflow's configuration. This is particularly useful when incident management practices need to be updated based on new requirements or lessons learned from previous incidents. The endpoint provides granular control over each step in the workflow, allowing for precise tuning of automated actions and their inputs. However, it's important to note that modifying a workflow may impact ongoing or future incident responses, so changes should be made thoughtfully and tested thoroughly before implementation in a production environment. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the incident workflow to update. | | `incident_workflow` | object | Yes | The incident workflow object containing the workflow definition to update. At least one field (name, description, team, or steps) must be provided. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update integration by id and integration id **Slug:** `PAGERDUTY_UPDATE_INTEGRATION_BY_ID_AND_INTEGRATION_ID` Updates an existing integration for a specific PagerDuty service. This endpoint allows you to modify the configuration of an integration, including its type, name, and various settings related to email processing for email-based integrations. It's particularly useful for adjusting how incoming data (especially emails) is processed and turned into incidents. Use this endpoint when you need to change the behavior of an existing integration, such as updating email parsing rules, changing incident creation criteria, or modifying email filters. The endpoint requires the service ID and integration ID in the URL path, and expects a comprehensive integration object in the request body. Note that some fields like 'id', 'created_at', and 'html_url' are read-only and cannot be modified through this endpoint. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the service. | | `integration` | object | Yes | The integration object with fields to update. | | `integration_id` | string | Yes | The integration ID on the service. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update integration label **Slug:** `PAGERDUTY_UPDATE_INTEGRATION_LABEL` This endpoint updates the label (name) of an integration associated with a specific event orchestration in PagerDuty. It allows users to rename integrations for better organization and clarity within their incident management workflow. The endpoint should be used when there's a need to change how an integration is identified within the PagerDuty system, such as after a service rename or to improve naming conventions. It's important to note that this endpoint only updates the label of the integration and does not modify any other properties or configurations of the integration or event orchestration. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | | `integration_id` | string | Yes | The ID of an Integration. | | `integration__label` | string | No | Name of the Integration. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update log entry channel **Slug:** `PAGERDUTY_UPDATE_LOG_ENTRY_CHANNEL` Updates collaboration channel information for a specific log entry in PagerDuty. This endpoint is specifically designed for updating details of Slack, Microsoft Teams, or Zoom channels that were created when responders were added to an incident. Use this to correct or update channel URLs, names, or other channel-specific metadata after the channel has been created. Important: This endpoint only works with log entries that have integration channels (Slack/Teams/Zoom). It cannot be used on standard log entries like triggers, acknowledgements, or website actions. The channel type cannot be changed - it must match the existing type and is required for validation. Common use case: After a Slack channel is created for incident collaboration, use this endpoint to update the channel URL or other details if they need correction. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `channel__type` | string ("web_trigger" | "mobile") | Yes | Channel type that must match the existing channel type of the log entry. This parameter is required for validation but cannot change the existing type. Supported types include 'web_trigger' and 'mobile'. | | `channel__details` | string | Yes | New channel details to update for the log entry. The specific format of details depends on the channel type (e.g., Slack channel URL, Teams channel info, Zoom meeting link). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update maintenance window by id **Slug:** `PAGERDUTY_UPDATE_MAINTENANCE_WINDOW_BY_ID` Updates an existing maintenance window in PagerDuty's incident management system. This endpoint allows you to modify the details of a scheduled maintenance period, including its start and end times, affected services, and description. It's used to adjust planned maintenance activities, ensuring that incidents are not created for specified services during the defined timeframe. The endpoint requires the maintenance window's unique ID and accepts a JSON object with the updated information. It's particularly useful for extending or shortening maintenance periods, changing the list of affected services, or updating the window's description in response to changing maintenance requirements. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the maintenance window to update. | | `maintenance_window` | object | Yes | The maintenance window object with fields to update | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update oncall handoff notification rule **Slug:** `PAGERDUTY_UPDATE_ONCALL_HANDOFF_NOTIFICATION_RULE` This endpoint updates an existing on-call handoff notification rule for a specific user in PagerDuty. It allows you to modify the notification delay, handoff type, and contact method for the rule. Use this endpoint when you need to change how and when a user is notified about upcoming on-call shifts or when they are going off-call. The endpoint requires both the user ID and the specific rule ID in the URL path. You can update the notification delay (in minutes), the type of handoff (both, oncall, or offcall), and the preferred contact method for the notification. This endpoint is particularly useful for adjusting notification preferences as team structures or individual availability changes. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user for whom to update the handoff notification rule. | | `oncall_handoff_notification_rule_id` | string | Yes | The ID of the on-call handoff notification rule to update. This can be obtained from the retrieve_oncall_handoff_notification_rules action. | | `oncall__handoff__notification__rule__id` | string | No | The ID of the handoff notification rule in the request body. Should match the oncall_handoff_notification_rule_id path parameter. | | `oncall__handoff__notification__rule__handoff__type` | string ("both" | "oncall" | "offcall") | No | The type of handoff for which to send notifications. Must be one of: 'oncall' (notify when going on-call), 'offcall' (notify when going off-call), or 'both' (notify for both transitions). Defaults to 'both'. | | `oncall__handoff__notification__rule__contact__method` | object | Yes | The contact method to use for this notification rule. Must be an object with 'id' and 'type' fields. The 'id' should be a valid contact method ID for this user (obtainable via the retrieve_user_contact_methods_via_id action). The 'type' must be one of: 'email_contact_method', 'sms_contact_method', 'phone_contact_method', 'push_notification_contact_method', 'slack_contact_method', or 'whatsapp_contact_method'. Example: {'id': 'PXXXXXX', 'type': 'email_contact_method'} | | `oncall__handoff__notif__rule__notify__advance__in__minutes` | integer | No | The number of minutes before the handoff when the notification should be sent. Must be between 0 and 2880 (48 hours). If not specified, the existing value will be retained. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update orchestration router details **Slug:** `PAGERDUTY_UPDATE_ORCHESTRATION_ROUTER_DETAILS` Updates the configuration of an existing Event Orchestration Router in PagerDuty. This endpoint allows you to modify the rules and routing logic for incoming events, determining how they are directed to specific services. It's used to refine and adjust your incident management workflow by updating conditions, actions, and catch-all behavior for event routing. The update is comprehensive, meaning any omitted rules or details will be deleted from the existing configuration. Use this endpoint when you need to make changes to your event routing strategy or when adding new services or conditions to your orchestration setup. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | | `orchestration_path` | object | Yes | The router configuration containing sets of routing rules and catch-all actions. Must include: 'sets' (list with at least one rule set with id 'start'), 'catch_all' (object with 'actions' containing 'route_to' field - either a service ID or 'unrouted'). Optional fields include routing rules with conditions and actions within sets. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update response play by id **Slug:** `PAGERDUTY_UPDATE_RESPONSE_PLAY_BY_ID` Updates an existing Response Play in PagerDuty's incident management system. This endpoint allows you to modify various aspects of a Response Play, including its name, description, associated team, subscribers, responders, runnability, and conference details. Use this when you need to alter the behavior or configuration of an existing Response Play to better suit your incident response processes. The update is performed by specifying the Response Play's unique identifier and providing the updated information in the request body. This endpoint is particularly useful for refining your incident management automation based on evolving team structures, communication preferences, or response strategies. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the response play to update. | | `response__play__name` | string | No | The new name for the Response Play. This is a human-readable identifier. | | `response__play__team__id` | string | No | The ID of the team that should own this Response Play. | | `response__play__description` | string | No | The new description for the Response Play. This provides context about when and how to use this response play. | | `response__play__runnability` | string | No | Who can run this Response Play. Valid values: 'services' (can be attached to services), 'responders' (can be run by responders), or 'services_and_responders' (both). | | `response__play__conference__url` | string | No | The conference URL to use when this Response Play runs. | | `response__play__conference__number` | string | No | The conference phone number to use when this Response Play runs. | | `response__play__responders__message` | string | No | The message to send to responders when this Response Play runs. | | `response__play__subscribers__message` | string | No | The message to send to subscribers when this Response Play runs. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update ruleset by id **Slug:** `PAGERDUTY_UPDATE_RULESET_BY_ID` Updates an existing ruleset in the PagerDuty incident management system. This endpoint allows you to modify the name of a ruleset or change its team association. It's used when you need to adjust the configuration of a specific ruleset, such as renaming it for better clarity or reassigning it to a different team. The endpoint requires the ruleset's unique ID and accepts updates to the name and team fields. It's important to note that other fields like routing keys, creation details, and update history are read-only and cannot be modified through this call. This endpoint is particularly useful for maintaining and organizing rulesets as your incident management needs evolve. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `ruleset__id` | string | No | ID of the Ruleset. | | `ruleset__name` | string | No | Name of the Ruleset. | | `ruleset__self` | string | No | the API show URL at which the object is accessible | | `ruleset__type` | string ("global" | "default_global") | No | Type | | `ruleset__team__id` | string | No | Id | | `ruleset__team__self` | string | No | The API show URL at which the object is accessible | | `ruleset__team__type` | string | No | A string that determines the schema of the object | | `ruleset__created__at` | string | No | The date the Ruleset was created at. | | `ruleset__creator__id` | string | No | Id | | `ruleset__updated__at` | string | No | The date the Ruleset was last updated. | | `ruleset__updater__id` | string | No | Id | | `ruleset__creator__self` | string | No | The API show URL at which the object is accessible | | `ruleset__creator__type` | string | No | A string that determines the schema of the object | | `ruleset__routing__keys` | array | No | Routing keys routed to this Ruleset. | | `ruleset__updater__self` | string | No | The API show URL at which the object is accessible | | `ruleset__updater__type` | string | No | A string that determines the schema of the object | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update schedule by id **Slug:** `PAGERDUTY_UPDATE_SCHEDULE_BY_ID` The UpdateSchedule endpoint modifies an existing on-call schedule in PagerDuty. It updates the schedule's name, time zone, description, and layers. Each layer defines a rotation pattern for on-call duties. Use this to adjust rotations, add/remove users, change time zones, or modify restrictions. Note: This replaces the entire schedule configuration, so include all desired layers and settings, even if only changing part of the schedule. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the schedule to update. | | `overflow` | boolean | No | Any on-call schedule entries that pass the date range bounds will be truncated at the bounds, unless the parameter `overflow=true` is passed. This parameter defaults to false. For instance, if your schedule is a rotation that changes daily at midnight UTC, and your date range is from `2011-06-01T10:00:00Z` to `2011-06-01T14:00:00Z`: - If you don"t pass the `overflow=true` parameter, you will get one schedule entry returned with a start of `2011-06-01T10:00:00Z` and end of `2011-06-01T14:00:00Z`. - If you do pass the `overflow=true` parameter, you will get one schedule entry returned with a start of `2011-06-01T00:00:00Z` and end of `2011-06-02T00:00:00Z`. | | `schedule` | object | Yes | The complete schedule object to update. This replaces the entire schedule configuration. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update service by id **Slug:** `PAGERDUTY_UPDATE_SERVICE_BY_ID` Updates an existing service in PagerDuty with the provided configuration. This endpoint allows you to modify various aspects of a service, such as its name, description, escalation policy, incident urgency rules, and alert grouping settings. Use this when you need to change the behavior or properties of an existing service. The endpoint requires the service ID and accepts a 'service' object containing the updated configuration. Note that some properties (like 'id' and 'created_at') are read-only and cannot be modified. Certain advanced features, such as alert grouping and auto-pause notifications, may only be available on specific PagerDuty plans. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the service to update. | | `service` | object | Yes | The service object with fields to update. Only include fields you want to modify. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update service orchestration active status **Slug:** `PAGERDUTY_UPDATE_SERVICE_ORCHESTRATION_ACTIVE_STATUS` Update the active status of a service orchestration in PagerDuty. This endpoint enables or disables event orchestration for a specific service. When orchestration is active (true), incoming events are processed through the service's orchestration rules. When inactive (false), events bypass orchestration and use the service's default incident creation behavior. **Common use cases:** - Temporarily disable orchestration during maintenance windows - Enable orchestration after configuring new rules - Troubleshoot event routing by toggling orchestration on/off **Requirements:** - Valid service_id with an existing service orchestration - API token with write permissions (services.write scope) - The service must have orchestration configured **Important:** Disabling orchestration affects how events are routed and incidents are created for this service. Test changes in a development environment first when possible. **Scoped OAuth required:** services.write #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `active` | boolean | Yes | Whether the service orchestration should be active (true) or inactive (false). When active=true, events sent to this service will be processed through the orchestration rules. When active=false, events will bypass orchestration and be handled using the service's default settings. | | `service_id` | string | Yes | The ID of the PagerDuty service whose orchestration active status you want to update. This is the unique identifier for the service (e.g., 'PG9JLO3'). You can obtain service IDs from the list services endpoint or from the service's page URL in the PagerDuty web app. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update standard by id **Slug:** `PAGERDUTY_UPDATE_STANDARD_BY_ID` Updates an existing standard in the PagerDuty incident management platform. This endpoint allows you to modify various attributes of a standard, including its active status, filtering criteria, description, and the technical services it applies to. Use this when you need to adjust the scope or behavior of an existing standard, such as enabling or disabling it, refining its application using regex patterns, or updating the list of included or excluded services. The changes made through this endpoint will affect how the standard is applied to your incident management processes, potentially impacting alerting and response workflows for the associated services. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | Unique identifier of the standard to update. | | `active` | boolean | No | Whether the standard is currently active. Set to true to enable the standard or false to disable it. | | `exclusions` | array | No | List of resources (e.g., services) specifically excluded from this standard's scope. Each exclusion can contain filters like id or regex patterns. | | `inclusions` | array | No | List of resources (e.g., services) specifically included in this standard's scope. Each inclusion can contain filters like id or regex patterns. | | `description` | string | No | Detailed description of what the standard checks and why it's important. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update status page post **Slug:** `PAGERDUTY_UPDATE_STATUS_PAGE_POST` Updates an existing status page post update with new information. This endpoint modifies a specific update within a status page post, allowing you to change the message content, status (e.g., investigating, identified, monitoring, resolved), severity level, impacted services, and notification preferences. Use this to communicate progress on an ongoing incident or maintenance event. For example, you might update a post to change status from 'investigating' to 'identified' as you learn more about an issue, or update the message with new information about a fix being deployed. Required path parameters: - id: Status page ID (get from PAGERDUTY_FETCH_STATUS_PAGES) - post_id: Post ID (get from PAGERDUTY_CREATE_OR_UPDATE_STATUS_PAGE_POST) - post_update_id: Update ID (get from PAGERDUTY_CREATE_OR_UPDATE_STATUS_PAGE_POST_UPDATE_INFORMATION) The post_update object must include: message, status ID, severity ID, impacted services list, update frequency, notify_subscribers flag, and type field. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The unique identifier of the status page. You can obtain this from PAGERDUTY_FETCH_STATUS_PAGES action. | | `post_id` | string | Yes | The unique identifier of the status page post. You can obtain this from PAGERDUTY_CREATE_OR_UPDATE_STATUS_PAGE_POST or PAGERDUTY_RETRIEVE_STATUS_PAGE_POST actions. | | `post_update_id` | string | Yes | The unique identifier of the post update to modify. You can obtain this from PAGERDUTY_CREATE_OR_UPDATE_STATUS_PAGE_POST_UPDATE_INFORMATION or PAGERDUTY_FETCH_POST_UPDATE_STATUS actions. | | `post__update__self` | string | No | The path to which the Post Update resource is accessible. | | `post__update__type` | string | No | The type identifier for the update object. Must be 'status_page_post_update'. | | `post__update__message` | string | No | The update message text to communicate to status page viewers. This describes the current situation, progress, or resolution status. For example: 'We have identified the issue and are deploying a fix' or 'Services have been restored and we are monitoring for stability'. | | `post__update__post__id` | string | No | Status page post unique identifier | | `post__update__post__type` | string | No | The type identifier for the post reference. Should be 'status_page_post_reference'. | | `post__update__status__id` | string | No | The ID of the status level for this update (e.g., 'investigating', 'identified', 'monitoring', 'resolved' for incidents, or 'scheduled', 'in_progress', 'completed' for maintenance). Get available status IDs from PAGERDUTY_GET_STATUS_FOR_STATUS_PAGE_BY_ID. | | `post__update__reported__at` | string | No | The date and time the Post Update was reported. | | `post__update__severity__id` | string | No | The ID of the severity level (e.g., 'minor', 'major', 'critical' for incidents, or 'maintenance', 'no_impact' for planned work). Get available severity IDs from PAGERDUTY_RETRIEVE_STATUS_PAGE_SEVERITIES_BY_ID. | | `post__update__status__type` | string | No | The type identifier for the status reference. Should be 'status_page_status_reference'. | | `post__update__severity__type` | string | No | The type identifier for the severity reference. Should be 'status_page_severity_reference'. | | `post__update__impacted__services` | array | No | List of status page services affected by this update, along with their impact levels. Each entry specifies a service_id (from PAGERDUTY_RETRIEVE_SERVICE_STATUS_BY_ID), service_type ('status_page_service_reference'), impact_id (from PAGERDUTY_GET_STATUS_PAGE_IMPACTS_BY_ID), and impact_type ('status_page_impact_reference'). Example impacts: 'operational', 'degraded_performance', 'partial_outage', 'major_outage'. | | `post__update__notify__subscribers` | boolean | No | Whether to send notifications to status page subscribers about this update. Set to true to notify subscribers via their configured channels (email, SMS, etc.), or false to update silently without sending notifications. | | `post__update__update__frequency__ms` | integer | No | The expected time until the next update in milliseconds. This helps set subscriber expectations for follow-up communications. For example: 3600000 for 1 hour, 1800000 for 30 minutes. Set to 0 if no further updates are expected. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update status page post info **Slug:** `PAGERDUTY_UPDATE_STATUS_PAGE_POST_INFO` Creates or updates a post update on a specific PagerDuty status page. This endpoint allows you to add new information or modify existing updates related to an incident or maintenance event. Use this when you need to communicate changes in status, provide additional details, or update the severity of an ongoing situation. The post update can include a custom message, current status, severity level, and list of impacted services. You can also control whether subscribers should be notified and optionally schedule future updates. This tool is essential for maintaining clear and timely communication with stakeholders during incidents or planned maintenance periods. Note that this endpoint does not create new status page posts; it only adds updates to existing posts. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page. You can get status page IDs from the 'Fetch Status Pages' action. | | `post_id` | string | Yes | The ID of the status page post to add an update to. You can get post IDs from the 'Retrieve Status Page Post' or 'Create Or Update Status Page Post' actions. | | `post__update__self` | string | No | The path to which the Post Update resource is accessible. | | `post__update__type` | string | Yes | The type identifier for the update object. Must be 'status_page_post_update'. | | `post__update__message` | string | Yes | The update message text to communicate to status page viewers. This describes the current status or provides information about the incident/maintenance. | | `post__update__post__id` | string | Yes | The ID of the status page post this update belongs to. Must match the 'post_id' path parameter. | | `post__update__post__type` | string | No | The type identifier for the post object. Should be 'status_page_post'. | | `post__update__status__id` | string | Yes | The ID of the current status level (e.g., 'investigating', 'identified', 'monitoring', 'resolved' for incidents). You can get status IDs from the 'Retrieve Status Pages Status' action. | | `post__update__reported__at` | string | No | The date and time the post update was reported in ISO 8601 format (e.g., '2026-01-29T12:00:00Z'). If not provided, defaults to the current time. | | `post__update__severity__id` | string | Yes | The ID of the severity level (e.g., 'minor', 'major', 'critical') indicating the impact of this update. You can get severity IDs from the 'Retrieve Status Page Severities By Id' action. | | `post__update__status__type` | string | No | The type identifier for the status object. Should be 'status_page_status'. | | `post__update__severity__type` | string | No | The type identifier for the severity object. Should be 'status_page_severity'. | | `post__update__impacted__services` | array | Yes | List of services affected by this update, along with their impact levels. Each entry specifies which service is impacted and the severity of that impact. | | `post__update__notify__subscribers` | boolean | Yes | Whether to send notifications to status page subscribers about this update. Set to true to notify subscribers, false to post silently. | | `post__update__update__frequency__ms` | integer | Yes | The expected time until the next update in milliseconds. For example, 3600000 for 1 hour. This helps set subscriber expectations for follow-up communications. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update status page post postmortem **Slug:** `PAGERDUTY_UPDATE_STATUS_PAGE_POST_POSTMORTEM` Updates an existing postmortem for a specific status page post in PagerDuty. This endpoint allows you to modify the postmortem message and notification settings for an incident's detailed analysis. The postmortem provides insights about the incident's root causes, impact, and lessons learned. Use this when you need to revise or enhance an existing postmortem after it has been created. The postmortem message supports Rich-Text formatting (max 10,000 characters) and you can control whether subscribers receive notifications about the update. Note: This endpoint updates an existing postmortem - use POST to create a new one. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the Status Page. | | `post_id` | string | Yes | The ID of the Status Page Post. | | `postmortem__type` | string ("status_page_post_postmortem") | No | The type of the object returned by the API - in this case, a Status Page Post Postmortem. | | `postmortem__message` | string | Yes | The message content of the Postmortem (supports Rich-Text formatting, max 10,000 characters). | | `postmortem__post__id` | string | Yes | The ID of the Status Page Post to which this postmortem belongs. Should match the post_id path parameter. | | `postmortem__post__type` | string | No | The type of the post object - typically 'status_page_post'. | | `postmortem__notify__subscribers` | boolean | Yes | Whether subscribers of the Status Page should be notified about the Postmortem. Set to true to send notifications, false otherwise. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update status page post resource **Slug:** `PAGERDUTY_UPDATE_STATUS_PAGE_POST_RESOURCE` Updates an existing status page post on a PagerDuty Status Page. Modify post details like title, type (incident/maintenance), and timing. Required fields: type, title, post_type, and status_page reference. For 'maintenance' posts, starts_at and ends_at are REQUIRED; for 'incident' posts, they should be null/omitted. Use this to update ongoing incidents or adjust maintenance windows. Note: This updates post metadata, not status updates within the post. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the status page. You can get status page IDs from the 'Fetch Status Pages' action. | | `post_id` | string | Yes | The ID of the status page post to update. You can get post IDs from the 'Get Post From Status Page By Id' action or from the response of 'Create Or Update Status Page Post'. | | `post__type` | string ("status_page_post") | No | The type identifier for the post object. Must be 'status_page_post'. Defaults to 'status_page_post'. | | `post__title` | string | No | The title of the status page post. This will be displayed prominently to status page viewers. Required field. | | `post__ends__at` | string | No | The end date and time for the maintenance window in ISO 8601 format (e.g., '2026-01-29T13:00:00Z'). Required when post_post_type is 'maintenance'. For 'incident' posts, set to null or omit. | | `post__post__type` | string ("incident" | "maintenance") | No | The type of post: 'incident' for service disruptions or ongoing issues, or 'maintenance' for scheduled maintenance windows. Required field. | | `post__starts__at` | string | No | The start date and time for the maintenance window in ISO 8601 format (e.g., '2026-01-29T12:00:00Z'). Required when post_post_type is 'maintenance'. For 'incident' posts, set to null or omit. | | `post__status__page__id` | string | No | The ID of the status page. Must match the 'id' path parameter. If not provided, will be auto-populated from 'id'. | | `post__status__page__type` | string | No | The type identifier for the status page object. Should be 'status_page'. Defaults to 'status_page'. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update team by id **Slug:** `PAGERDUTY_UPDATE_TEAM_BY_ID` Updates an existing team in PagerDuty by modifying its name, description, visibility, or parent team. You can update: - name: Change the team name (must be unique) - description: Update team purpose/responsibilities - default_role: Change team visibility ('none' for private, 'manager' for public) - parent: Modify team hierarchy (requires Team Hierarchy feature) Provide only the fields you want to change. Other fields remain unchanged. Read-only fields like 'id', 'summary', 'self', and 'html_url' cannot be modified. Examples: - Rename: {"id": "PXXXXXX", "team": {"name": "New Team Name"}} - Make private: {"id": "PXXXXXX", "team": {"default_role": "none"}} - Update multiple: {"id": "PXXXXXX", "team": {"name": "Updated Team", "description": "New description", "default_role": "manager"}} Use this when reorganizing teams, changing visibility, or updating team information. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the team to update. | | `team` | object | Yes | The team object containing the fields to update. At least one field must be provided. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update template by id **Slug:** `PAGERDUTY_UPDATE_TEMPLATE_BY_ID` The UpdateTemplate endpoint allows you to modify an existing status update template in PagerDuty. This tool is used to customize notification templates for incident status updates, enabling consistent and efficient communication during incident management. It supports updating various aspects of the template, including its name, description, and content for different notification channels such as email and SMS. This endpoint is particularly useful when you need to refine or adjust your communication strategy for incident updates. Note that while you can update multiple fields, you cannot change the template type from 'status_update', as it's currently the only supported type. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the resource. | | `template__name` | string | No | The name of the template | | `template__description` | string | No | Description of the template | | `template__template__type` | string ("status_update") | No | The type of template (`status_update` is the only supported template at this time) | | `template__templated__fields__message` | string | No | The short-message of the template (SMS, Push notification, Slack, etc) | | `template__templated__fields__email__body` | string | No | The HTML body of the e-mail message | | `template__templated__fields__email__subject` | string | No | The subject of the e-mail | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update the service orchestration for a service **Slug:** `PAGERDUTY_UPDATE_THE_SERVICE_ORCHESTRATION_FOR_A_SERVICE` Update a Service Orchestration for a service. Service Orchestrations allow you to create Event Rules that evaluate and process events sent to this service. The orchestration_path parameter must include: - 'sets': List of rule sets (at least one with id='start'). Each set has 'id' and 'rules' list. - 'catch_all': Actions object for unmatched events (must have 'actions' key). Rules can have 'conditions' and 'actions' (severity, priority, annotate, suppress, event_action, etc.). Get current config first using get_the_service_orchestration_for_a_service, then modify and update. Scoped OAuth requires: `services.write` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `service_id` | string | Yes | The service ID | | `orchestration_path` | object | Yes | The service orchestration path configuration containing sets of rules and catch-all actions. Must include: 'sets' (a list of rule sets, with at least one set with id='start'), and 'catch_all' (actions object for events that don't match any rules). Each set contains an 'id' and a 'rules' list. Rules can contain 'conditions' (event matching criteria) and 'actions' (transformations like severity, priority, annotate, suppress, etc.). The catch_all contains an 'actions' object with fallback processing rules. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update unrouted orchestration rules **Slug:** `PAGERDUTY_UPDATE_UNROUTED_ORCHESTRATION_RULES` Updates the unrouted orchestration rules for a specific Event Orchestration in PagerDuty. This endpoint allows you to define how events that don't match any service-specific rules should be handled. It's used to create a fallback mechanism for event routing and manipulation, ensuring that all incoming events are processed appropriately. The update is comprehensive, meaning any omitted rules or rule details from the request will be deleted from the existing configuration. Use this endpoint when you need to modify the global handling of unrouted events, such as changing default severities, updating event summaries, or implementing new routing logic for unmatched events. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of an Event Orchestration. | | `orchestration_path` | object | Yes | The unrouted orchestration path configuration containing sets of rules and catch-all actions. Must include: 'sets' (a list of rule sets, with at least one set with id='start'), and 'catch_all' (fallback actions object). Each set contains an 'id' and a 'rules' list. Rules can contain 'conditions' and 'actions' for event routing and manipulation. The catch_all contains an 'actions' object with fallback processing rules (e.g., suppress: true/false). | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update user information **Slug:** `PAGERDUTY_UPDATE_USER_INFORMATION` Updates an existing user's information in PagerDuty. Modifies user profile attributes including name, email, time zone, role, job title, description, color, and license. Only include fields you want to update in the user object - all fields are optional. Updatable fields: name, email, role, time_zone, job_title, description, color, license Read-only fields (use dedicated endpoints): teams, contact_methods, notification_rules Note: Only include fields you want to change. Some roles require specific account abilities. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user to update | | `user` | object | Yes | User object containing the fields to update. Only include the fields you want to change. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update user status update notification rule by id **Slug:** `PAGERDUTY_UPDATE_USER_NOTIFICATION_RULE_BY_ID` Updates a specific status update notification rule for a PagerDuty user. This endpoint modifies how a user receives notifications about status updates on incidents they're subscribed to (as stakeholders, not as assigned responders). It allows you to change the contact method (email, phone, SMS, or push notification) for receiving these status updates. Note: This is for status update notifications, which are different from incident assignment notifications. Status updates notify subscribers about changes to incidents they're following. The contact method must already exist for the user before it can be associated with a notification rule. Use the user contact methods endpoints to manage available contact methods. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the user whose status update notification rule to update. | | `status_update_notification_rule` | object | Yes | The updated status update notification rule configuration. | | `status_update_notification_rule_id` | string | Yes | The ID of the status update notification rule to update. | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update user role on team **Slug:** `PAGERDUTY_UPDATE_USER_ROLE_ON_TEAM` Adds a user to a team or updates their role on a team. This endpoint manages team membership by assigning users to teams with specific roles. Use this to: - Add a new user to a team with a specified role - Update an existing team member's role (promote/demote) - Change a user's team permissions and responsibilities The role determines the user's access level within the team context: - 'manager': Can manage team settings, members, and associated resources - 'responder': Can respond to incidents assigned to the team - 'observer': Read-only access to team resources Note: This affects only the user's role for the specified team and does not modify their global account permissions or roles in other teams. Requires the Teams feature which is available on paid PagerDuty plans. #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the team. Example: 'P123ABC' | | `role` | string ("observer" | "responder" | "manager") | Yes | The role to assign to the user on the team. Options: 'observer' (read-only access), 'responder' (can respond to incidents), 'manager' (can manage team settings and members). | | `user_id` | string | Yes | The ID of the user to add to the team or whose role to update. Example: 'P456XYZ' | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not | ### Update workflow integration connection **Slug:** `PAGERDUTY_UPDATE_WORKFLOW_INTEGRATION_CONNECTION` Update an existing Workflow Integration Connection. Updates properties of a workflow integration connection such as name, service URL, authentication settings, and team permissions. This action is idempotent - sending the same update multiple times produces the same result. Scoped OAuth requires: `workflow_integrations:connections.write` #### Input Parameters | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `id` | string | Yes | The ID of the connection to update | | `name` | string | No | The display name for the connection | | `type` | string | No | The type of the connection (typically 'workflow_integration_connection') | | `teams` | array | No | The teams whose managers are allowed to use or edit this connection | | `scopes` | array | No | OAuth scopes or permissions granted to this connection | | `is_default` | boolean | No | Set to true to make this the default connection for the integration | | `external_id` | string | No | An external identifier for this connection in the remote system | | `service_url` | string | No | The base URL of the external service (e.g., 'https://api.example.com') | | `integration_id` | string | Yes | The ID of the workflow integration (e.g., 'http-api' for HTTP/Web API connections) | | `external_id_label` | string | No | A human-readable label for the external identifier | | `health__is__healthy` | boolean | No | Whether or not the connection is healthy | | `health__health__message` | string | No | A message describing the health of the connection | | `health__last__checked__at` | string | No | The timestamp of the last health check | #### Output | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | `data` | string | Yes | Data from the action execution | | `error` | string | No | Error if any occurred during the execution of the action | | `successful` | boolean | Yes | Whether or not the action execution was successful or not |