Pagerduty

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.

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.

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.

Retrieves all alerts associated with a specific incident in pagerduty. this endpoint allows users to fetch detailed information about the notifications and alerts that were triggered as part of an incident's lifecycle. it is particularly useful for incident postmortems, auditing purposes, or understanding the notification flow during an incident. the endpoint returns a list of alerts, which may include information such as alert creation time, alert status, and the targets (users or services) that received the notifications. it should be used when detailed alert information for a known incident is required, but it will not provide information about the incident itself beyond its associated alerts.

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.

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.

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.

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.

This endpoint adds a service to an existing incident workflow trigger in pagerduty. it allows you to associate a specific service with a trigger, enabling automated incident management processes for that service. use this endpoint when you need to connect a service to an incident workflow, typically during the setup or modification of your incident response procedures. the endpoint requires the trigger's id and the service's id to make the association. it's important to note that this operation doesn't create new services or triggers, but rather links existing ones. ensure that both the trigger and service exist in your pagerduty account before making this call.

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.

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.

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.

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.

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.

Converts the rules associated with a specific pagerduty service to a new or optimized format. this endpoint is used to update and standardize the incident management rules for a given service, improving the efficiency and consistency of alert handling. it should be used when there's a need to modernize rule sets, apply best practices, or adapt rules to changing service requirements. the conversion process is applied to all rules linked to the specified service id, potentially modifying their structure or behavior. it's important to note that this operation may impact existing incident routing and alerting patterns, so it should be used cautiously and preferably during a maintenance window.

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.

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.

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. <!-- theme: warning --> > ### 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`

Creates a new automation runner in the pagerduty incident management system. this endpoint allows you to set up either a sidecar runner, which polls for invocations externally, or a runbook runner, which communicates directly with a runbook instance. use this when you need to automate actions within pagerduty, such as incident response processes or scheduled tasks. the runner can be associated with specific teams for better organization and access control. note that the required parameters differ based on the chosen runner type, with runbook runners requiring additional configuration for server connection.

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. <!-- theme: warning --> > ### 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`

Create a field option for a custom field. 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. <!-- theme: warning --> > ### 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`

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.

Create new incident workflow trigger scoped oauth requires: `incident workflows.write`

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Creates a new integration within an existing event orchestration in pagerduty. this endpoint allows users to set up connections between pagerduty and external systems or services, enabling automated event management and incident response. it should be used when adding a new integration to an event orchestration, such as connecting a monitoring tool or alerting system. the endpoint requires minimal information, focusing on the integration's label for identification purposes. note that this endpoint only creates the integration; additional configuration may be required in the pagerduty interface or through other api calls to fully set up the integration's functionality.

This endpoint creates a new integration for a specific pagerduty service. it allows you to set up various types of integrations, including email-based and events api v2 integrations. the primary use case is to establish new channels for incident creation and management within a pagerduty service. this tool is particularly useful when setting up automated alerting systems or connecting external monitoring tools to pagerduty. the integration type and configuration options determine how incidents are triggered and processed. note that this endpoint focuses on creation only and does not handle updating or deleting existing integrations.

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.

Creates a new on-call schedule in pagerduty, defining rotation patterns for team members. this endpoint allows you to set up complex schedules with multiple layers, each having its own rotation pattern, user assignments, and time restrictions. use it to establish new on-call rotations, manage team availability, and ensure continuous incident response coverage. the created schedule can be used in escalation policies to determine who gets notified during incidents. note that while you can create a basic schedule structure, some elements like rendered schedule entries are read-only and will be populated by the system after creation.

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.

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.

Creates a new team within your pagerduty account. this endpoint allows you to establish a group of users with shared responsibilities, often used for organizing incident management and on-call schedules. use this when setting up a new department, project team, or any other group that needs to collaborate on incident responses. the created team can be configured as public or private, determining the level of access for non-members. note that while you can create the team structure with this call, you'll need separate api calls to add members or assign schedules to the team.

Creates a new post on a specified pagerduty status page. this endpoint allows you to publish information about incidents or scheduled maintenance, including details such as the post type, timing, and associated updates. use this to communicate service status, planned downtime, or ongoing issues to your users or customers. the post can include multiple updates, each with its own message, severity, and impact on specific services. this is particularly useful for providing real-time information during incidents or for scheduling and describing maintenance windows.

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.

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.

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.

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.

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.

Creates a new template in pagerduty for standardized status updates. this endpoint allows users to define customizable templates for various notification types, including emails and short messages. it's primarily used to streamline communication during incident management by providing consistent and pre-formatted status update messages. the template can include placeholders for dynamic content, allowing for personalized and context-specific notifications. this endpoint should be used when setting up new standardized communication formats for incident updates, but it's important to note that currently only 'status update' type templates are supported.

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.

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.

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.

Create a new workflow integration connection. scoped oauth requires: `workflow integrations:connections.write`

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.

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.

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.

Delete all oauth delegations as per provided query parameters. 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. at this time, this endpoint only supports deleting mobile app oauth delegations for a given user. this is equivalent to signing users out of the mobile app. this is an asynchronous api, the deletion request itself will be processed within 24 hours. scoped oauth requires: `oauth delegations.write`

Deletes a specific automation runner from the pagerduty system. this endpoint is used to permanently remove an automation runner, which is responsible for executing automated tasks and workflows. it should be used when an automation runner is no longer needed or needs to be replaced. once deleted, all associated automated actions and schedules tied to this runner will be affected. exercise caution when using this endpoint, as the deletion is irreversible and may impact existing automation setups.

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.

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.

Delete 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. <!-- theme: warning --> > ### 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`

Delete a field option for a custom field. <!-- theme: warning --> > ### 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`

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.

Deletes all priority thresholds for business services in the pagerduty account. this endpoint is used to remove the configured priority settings that determine how incidents are escalated based on their urgency for business services. it should be used when you want to reset or remove all priority threshold configurations across your business services. this operation is irreversible and will affect how future incidents are prioritized and escalated for all business services in the account. it's important to note that this action does not delete the business services themselves, only their associated priority thresholds.

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 permanent and cannot be undone, so it should be used with caution. the endpoint requires both the event orchestration id and the specific cache variable id to ensure precise removal of the intended data.

This endpoint deletes a specific cache variable associated with a service in pagerduty's event orchestration system. it is used to remove temporary data that is no longer needed, helping to maintain system efficiency. the endpoint should be used when you want to permanently remove a cache variable from a particular service, such as when the variable is obsolete or to free up resources. it's important to note that this action is irreversible, and once deleted, the cache variable cannot be recovered. use this endpoint with caution to avoid accidentally removing critical data used in event orchestrations.

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.

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.

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.

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.

This endpoint deletes a specific field option from a custom field in pagerduty's incident management system. it allows you to remove predefined options that are no longer needed or relevant for incident categorization or data collection. use this endpoint when you want to update the available options for a custom field by removing outdated or unnecessary choices. be cautious when using this endpoint, as deleting a field option may impact existing incidents that use this option and could affect reporting or automation based on these custom fields. this operation cannot be undone, so it's advisable to have a backup of your custom field configuration before making changes.

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.

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.

This endpoint removes a specific service from a trigger within an incident workflow in pagerduty. it is used to modify the configuration of an existing incident workflow by disassociating a service from a particular trigger. this action is useful when you need to update the automation rules or remove a service from the automated response process for certain incidents. the endpoint requires both the trigger id and the service id to be specified in the url path. upon successful execution, the specified service will no longer be associated with the trigger, affecting future incident workflow executions. this operation cannot be undone, so it should be used with caution to avoid disrupting critical incident management processes.

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.

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.

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.

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.

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.

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.

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.

Deletes a specific rule from a ruleset in pagerduty's incident management platform. this endpoint allows users to remove individual event rules, providing flexibility in managing and updating rulesets. it should be used when you need to eliminate an outdated, unnecessary, or incorrect rule from a ruleset. the operation is permanent and cannot be undone, so caution should be exercised when using this endpoint. it's important to note that deleting a rule may affect the event routing and actions defined in the ruleset, potentially impacting incident management workflows.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Deletes a specific team from the pagerduty system based on the provided team id. this endpoint should be used when you need to remove a team that is no longer required in your incident management structure. it's important to note that deleting a team is a permanent action and cannot be undone. before deletion, ensure that all associated users, schedules, and escalation policies have been properly reassigned or removed to prevent disruption to your incident management workflows. this operation does not delete the users within the team; it only removes the team structure itself.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Delete a workflow integration connection. scoped oauth requires: `workflow integrations:connections.write`

This endpoint disassociates service dependencies in pagerduty by deleting specified relationships between supporting and dependent services. it allows for the removal of multiple service dependencies in a single api call, enabling efficient management of service hierarchies and relationships within the pagerduty platform. the endpoint should be used when restructuring service dependencies, removing obsolete relationships, or updating the service topology. it's important to note that this operation is irreversible and will immediately affect the dependency structure of the services involved.

The updatewebhooksubscription endpoint allows you to modify an existing webhook subscription in pagerduty. this put method enables users to update the events they want to be notified about, change the filter criteria for triggering notifications, update the subscription's description, and toggle its active state. it's particularly useful for adjusting notification preferences as your incident management needs evolve. the endpoint requires specifying the webhook subscription id in the url path and accepts a json body with the updated subscription details. note that while you can update multiple aspects of the subscription, you must provide at least the 'events' array in your request. be cautious when updating filters, as this can significantly change which incidents trigger notifications.

Enables a specific extension in the pagerduty system. this endpoint is used to activate an extension that has been previously configured but is currently inactive. it allows users to turn on additional functionalities or integrations within their pagerduty account. the extension is identified by its unique id, which must be provided in the request path. this action is typically used when setting up new integrations, reactivating temporarily disabled features, or as part of automated workflows for managing pagerduty configurations. note that enabling an extension may have immediate effects on the account's behavior, such as allowing new types of alerts or activating connections with external services.

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.

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.

Retrieves detailed information about a specific cache variable within an event orchestration in pagerduty. this endpoint allows users to fetch the current state and configuration of a cache variable, which is used to store temporary data for optimizing event orchestration performance. it's particularly useful when you need to inspect or debug the cached data being used in your event orchestration workflows. the endpoint should be used when you need to verify the contents of a specific cache variable or when troubleshooting issues related to event orchestration data caching. note that this endpoint only provides read access to the cache variable and cannot be used to modify its contents.

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.

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.

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.

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.

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.

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.

Retrieves a list of change events related to a specific incident in pagerduty. this endpoint is used to gather contextual information about changes or updates associated with an incident, which can be crucial for understanding its progression and resolution. it provides insights into actions taken, system modifications, or other relevant events that occurred in connection with the incident. use this endpoint when investigating incident timelines, auditing response actions, or compiling comprehensive incident reports. note that this endpoint only returns change events directly linked to the specified incident and does not provide general incident details or unrelated events.