
PagerDuty
Incident Management- Overview
- Setup
- Data & mappings
- Operations & API
- Changelog
The PagerDuty connector integrates with the PagerDuty incident response platform via the PagerDuty REST API (v2). It synchronizes four object types — Services, Teams, Users, and Incidents — into the Brinqa platform, enabling visibility into on-call services, the teams responsible for them, the people who staff those teams, and the incidents triggered against them.
Data retrieved from PagerDuty
| Connector Object | Required | Maps to Data Model |
|---|---|---|
| Service | Yes | Application |
| Team | Yes | Team |
| User | Yes | Person |
| Incident | Yes | Incident |
Model relationships
For detailed steps on how to view the data retrieved from PagerDuty in the Brinqa Platform, see How to view your data.
Connection settings
When setting up a data integration, select PagerDuty from the Connector dropdown and provide the following:
| Setting | Required | Default | Description |
|---|---|---|---|
| API URL | Yes | — | PagerDuty API URL |
| Token | No | — | PagerDuty API Token |
| Page size | No | 100 | Maximum number of records to get per API request |
| Parallel requests | No | min(4, availableProcessors) | Maximum number of parallel API requests |
| Max retries | No | 10 | Specifies the maximum number of retries permitted during a request. The default value is 10. |
Authentication
The connector authenticates with the PagerDuty REST API using a PagerDuty API access token sent on every request as a custom Authorization: Token token=<TOKEN> header. No token-exchange step is performed — the token configured on the connector is sent directly with each call.
Method
| Element | Value |
|---|---|
| Method | API Key (PagerDuty Token) |
| Token Source | Configured by the user on the connector (accessToken property) |
| Token Type | PagerDuty REST API Token (User token or General Access Token) |
Endpoint
PagerDuty does not require a separate authentication endpoint — the token is sent as a header on each API call. A connection test is performed against:
| Method | URL |
|---|---|
GET | {url}/incidents?limit=1 |
Request Headers
The following headers are set on every outbound request by the connector:
| Header | Value |
|---|---|
Content-Type | application/json |
Accept | application/json, application/vnd.pagerduty+json;version=2 |
Authorization | Token token=<accessToken> |
Request Body
None. Authentication is performed entirely through the Authorization header — there is no token-exchange request and no request body is sent.
Sample Response
A successful test call returns a standard paginated response of the form:
{
"incidents": [ ... ],
"limit": 1,
"offset": 0,
"more": false,
"total": null
}
On failure, PagerDuty returns an error payload of the form:
{
"error": {
"message": "Invalid Input Provided",
"code": 2001,
"errors": [ "..." ]
}
}
Response Fields
| Field | Type | Description |
|---|---|---|
<resource> | array | List of resources for the requested object type (users, teams, services, incidents) |
limit | integer | Maximum number of records returned per page |
offset | integer | Pagination offset of the current page |
more | boolean | Indicates whether additional pages are available |
total | integer | Total number of records (may be null when not computed by the API) |
Usage
Once configured, every API request sent by the connector includes the static authorization header:
Authorization: Token token=<accessToken>
Accept: application/json, application/vnd.pagerduty+json;version=2
Content-Type: application/json
Pagination is handled with the limit and offset query parameters, with the page size controlled by the pageSize configuration property.
Sync Behavior
The connector supports incremental (delta) syncs. It maintains a sync token between runs and applies it as an incremental timestamp filter, so each run re-processes only the records that changed after the previous sync. The initial run retrieves the complete data set; later runs are incremental. The specific timestamp field applied to each object is documented under that object's Sync Duration Parameter.
How to obtain PagerDuty credentials
Generate a PagerDuty API access token
For the PagerDuty connector to retrieve data from the PagerDuty API, you must provide a PagerDuty API access token. You can create a User token or a General Access Token from your PagerDuty account settings. For additional information, see PagerDuty API reference documentation.
Attribute mappings
Expand the sections below to view the mappings between the source and the Brinqa data model attributes:
Service
| Source Field Name | SDM Attribute |
|---|---|
service.acknowledgement_timeout | ACKNOWLEDGMENT_TIMEOUT |
service.addons[].id | ADDONS |
service.alert_creation | ALERT_CREATION |
service.alert_grouping | ALERT_GROUPING |
service.alert_grouping_parameters.config | ALERT_GROUPING_PARAMETER |
service.alert_grouping_timeout | ALERT_GROUPING_TIMEOUT |
service.auto_pause_notifications_parameters.enabled | AUTO_PAUSE_NOTIFICATIONS |
service.auto_resolve_timeout | AUTO_RESOLVE_TIMEOUT |
service.created_at | SOURCE_CREATED_DATE |
service.description | DESCRIPTION |
service.escalation_policy.id | ESCALATION_POLICY |
service.html_url | URL |
service.id | UID |
service.incident_urgency_rule.urgency | INCIDENT_URGENCY |
service.integrations[].id | INTEGRATIONS |
service.last_incident_timestamp | LAST_INCIDENT_TIMESTAMP |
service.name | NAME |
service.response_play.id | RESPONSE_PLAY |
service.scheduled_actions[].type | SCHEDULED_ACTIONS |
service.self | SELF |
service.status | STATUS |
service.summary | SUMMARY |
service.support_hours.days_of_week | SUPPORT_HOURS_DAYS |
service.support_hours.end_time | SUPPORT_HOURS_END_TIME |
service.support_hours.start_time | SUPPORT_HOURS_START_TIME |
service.support_hours.time_zone | SUPPORT_HOURS_TIME_ZONE |
service.support_hours.type | SUPPORT_HOURS_TYPE |
service.teams[].id | TEAM_IDS |
service.updated_at | SOURCE_LAST_MODIFIED |
Team
| Source Field Name | SDM Attribute |
|---|---|
team.default_role | DEFAULT_ROLE |
team.description | DESCRIPTION |
team.html_url | HTML_URL |
team.id | UID |
team.name | NAME |
team.parent.id | PARENT |
team.self | SELF |
team.summary | SUMMARY |
team.type | TEAM_TYPE |
User
| Source Field Name | SDM Attribute |
|---|---|
user.avatar_url | AVATAR_URL |
user.billed | BILLED |
user.color | COLOR |
user.contact_methods[].id | CONTACT_METHODS |
user.description | DESCRIPTION |
user.email | |
user.html_url | HTML_URL |
user.id | UID |
user.invitation_sent | INVITATION_SENT |
user.job_title | JOB_TITLE |
user.name | NAME |
user.notification_rules[].id | NOTIFICATION_RULES |
user.role | ROLE |
user.self | SELF |
user.summary | SUMMARY |
user.teams[].id | TEAMS |
user.time_zone | TIMEZONE |
user.type | USER_TYPE |
Incident
| Source Field Name | SDM Attribute |
|---|---|
incident.acknowledgements[].acknowledger.id | ACKNOWLEDGER_IDS |
incident.alert_counts.all | ALERTS_COUNT |
incident.assigned_via | ASSIGNED_VIA |
incident.assignments[].assignee.id | ASSIGNMENT_ASSIGNEE_IDS |
incident.body.details | BODY |
incident.body.type | BODY_TYPE |
incident.conference_bridge.conference_number | CONFERENCE_BRIDGE |
incident.created_at | SOURCE_CREATED_DATE |
incident.escalation_policy.id | ESCALATION_POLICY |
incident.first_trigger_log_entry.id | FIRST_TRIGGER_LOG_ENTRY |
incident.html_url | HTML_URL |
incident.id | UID |
incident.incident_key | INCIDENT_KEY |
incident.incident_number | INCIDENT_NUMBER |
incident.incidents_responders[].user.id | INCIDENT_RESPONDER |
incident.last_status_change_at | LAST_STATUS_CHANGE_AT |
incident.last_status_change_by.id | LAST_STATUS_CHANGE_BY |
incident.occurrence.count | OCCURRENCE |
incident.pending_actions[].type | PENDING_ACTIONS |
incident.priority.id | PRIORITY |
incident.resolve_reason.incident.id | RESOLVE_REASON_INCIDENT |
incident.resolve_reason.type | RESOLVE_REASON_TYPE |
incident.responder_requests[].requester.id | INCIDENT_REQUESTER |
incident.self | SELF |
incident.service.id | SERVICE_ID |
incident.status | STATUS |
incident.summary | SUMMARY |
incident.teams[].id | TEAM_IDS |
incident.title | TITLE |
incident.type | TYPE |
incident.urgency | URGENCY |
Operations & API
Expand each connector object to see its operation options, delta-sync behavior, and the API it uses. See connector operation options for how to apply operation options (keys and values are case-sensitive).
Service
Operation options
This object does not support any operation options.
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
GET /services
Team
Operation options
This object does not support any operation options.
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
GET /teams
User
Operation options
This object does not support any operation options.
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
GET /users
Incident
Operation options
This object does not support any operation options.
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
GET /incidents - Default filters:
since=<timestamp>when the syncsincefalls within the last six months, otherwisedate_range=all
Changelog
The PagerDuty connector has undergone the following changes:
| Version | Description | Migration Steps |
|---|---|---|
| 3.0.0 | Improvements - Timestamp attributes ( LAST_STATUS_CHANGE_AT on Incident; SOURCE_CREATED_DATE and LAST_INCIDENT_TIMESTAMP on Service) are now returned as proper datetime values instead of numeric epoch milliseconds, enabling accurate time-based filtering and display. - Internal framework upgrade: models now use a shared connector base class, improving consistency and maintainability across the connector platform. | • Incident: LAST_STATUS_CHANGE_AT changed from a numeric epoch value (Long) to a datetime (Instant) — Action: re-sync • Service: SOURCE_CREATED_DATE and LAST_INCIDENT_TIMESTAMP changed from numeric epoch values (Long) to datetimes (Instant) — Action: re-sync |