canonical: https://jentic.com/apis/pagerduty.com/pagerduty

# PagerDuty API

This document describes the PagerDuty REST APIs.

For guides and examples please visit our [Documentation.](https://developer.pagerduty.com/docs/get-started/getting-started/)

Our REST APIs are defined in OpenAPI v3.x. You can view the schema at [github.com/PagerDuty/api-schema](https://github.com/PagerDuty/api-schema).

Note that properties in some schemas have fields not shown by default such as `readOnly`, `format`, and `default`. Hover your cursor over the right column that looks like `optional+1` to see the full list of fields.

## For AI agents

This document describes the PagerDuty REST APIs.

For guides and examples please visit our [Documentation.](https://developer.pagerduty.com/docs/get-started/getting-started/)

Our REST APIs are define...

## Scope

Provides access to PagerDuty API functionality as defined in the OpenAPI specification.

## Capabilities

- Assign tags
- Get tags for entities
- List abilities
- Test an ability
- List installed Add-ons
- Install an Add-on

## Use cases

### Basic PagerDuty API Integration

Integrate PagerDuty API into your application to access its core functionality.

Example prompt: Use the PagerDuty API API to access vendor services and data.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /{entity_type}/{id}/change_tags | Assign tags |
| GET | /{entity_type}/{id}/tags | Get tags for entities |
| GET | /abilities | List abilities |
| GET | /abilities/{id} | Test an ability |
| GET | /addons | List installed Add-ons |
| POST | /addons | Install an Add-on |
| GET | /addons/{id} | Get an Add-on |

## Key resources

- **Main API** — Primary PagerDuty API resources and operations

## Why Jentic

- **Setup:** Wiring PagerDuty by hand means handling its API-key auth in the Authorization header against api.pagerduty.com, shaping requests across many resource types, and building your own retry and error handling. Through Jentic you install once, import the PagerDuty API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** PagerDuty puts the resource id in the URL path (/{entity_type}/{id}/change_tags), so a rule can pin your agent to a specific entity and the operations you approve. You choose the operations it may call, so writes like changing tags or creating add-ons are not included unless you add them.
- **Credential handling:** Your PagerDuty key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'list PagerDuty add-ons' or 'change tags on an entity', and Jentic returns the matching PagerDuty operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## FAQ

### What authentication does the PagerDuty API use?

The PagerDuty API uses apiKey authentication.

### How many endpoints does the PagerDuty API have?

The PagerDuty API has 420 endpoints available.

### Can I limit what my agent is allowed to do with the PagerDuty API?

Yes. Because you host Jentic One yourself, your own rules decide which PagerDuty operations and credentials the agent may use. Since PagerDuty puts the resource id in the URL path, such as /{entity_type}/{id}/change_tags, you can pin the agent to a specific entity and only the operations you approve. Read-only calls like listing abilities or getting an add-on can be allowed while writes such as changing tags or installing an add-on stay excluded until you add them.