How to integrate Unify with PagerDuty

To integrate Unify with PagerDuty, send a Play webhook to an authenticated receiver that your team configures. The receiver calls PagerDuty, manages its credentials, and tracks the result. Use this connection to escalate a narrowly defined operational exception to PagerDuty.[1][2][3][4]

By UnifyDocumentation reviewed September 15, 2026

Explore scenarios Technical setup Open Unify

Connection: Via intermediary; Observability
Tool: PagerDuty; Custom receiver, then PagerDuty
Data flow: Unify → Your receiver → PagerDuty; JSON payload

At a glance

Via intermediary: your receiver calls PagerDuty
POST request with an explicit JSON contract and destination authentication
Test scenario: Prevent repeated paging

When this workflow makes sense

Start with the decision your team needs to make, then choose the connection that supports it.

On-call systems should receive events that justify interruption. Define the business exception, its owner, and the condition that resolves it. Keep routine lead alerts in a collaboration tool so urgent signals remain distinguishable.

A good fit when

Teams that want to escalate a narrowly defined operational exception to PagerDuty and have an owner for the receiving process. A developer or automation owner must maintain the receiver and its credentials.

Reconsider the plan when

There is no owner for the receiver, credential lifecycle, or recovery process. Assign that responsibility before using PagerDuty for a live handoff.

Design the handoff

Use this framework to agree on the input, the next action, and who owns the result.

Suggested workflow design, based on the documented capabilities below.

Stage	Decision to make
Business decision	Escalate a narrowly defined operational exception to PagerDuty
Receiving contract	Agree which of the 5 example data fields the receiving process actually needs. Set missing-value and identity rules in the field mapping below.
Execution boundary	Assign an owner for the HTTPS receiver, credentials, and PagerDuty operation.
Completion	Decide who can confirm the PagerDuty outcome and recover a failed or repeated handoff. Use the completion check below as the acceptance criterion.

Explore the scenarios

Choose the situation that fits your team and work through the proposed plan.

Open a scenario to explore its plan. Checklists track your selections in this page only.

Escalate a narrowly defined operational exception to PagerDuty

Start with one controlled record and one intended PagerDuty outcome. Keep the test destination separate from live operations.

The decision that matters

The receiving owner must distinguish accepted input from completed work. Agree on the evidence required before treating this handoff as successful.

Prepare the destination using the PagerDuty setup checklist
Resolve the sample fields for one known record and inspect the request before sending it
Trace that handoff through the receiving operation and compare the actual destination values with the source

Your validation checklistThe PagerDuty destination and record identity are correctThe required fields match the controlled recordThe completion evidence is saved and the next action has an owner

0 of 3 checks marked by you

Prevent repeated paging

Prevent repeated paging: send the same controlled exception through the receiver twice, inspect grouping, then resolve it using the same incident identity. Confirm a new business exception is treated separately.

The decision that matters

Decide whether this case should be held for review, corrected, or retried. Make that decision before running PagerDuty against live records.

Isolate the test in a controlled destination and record the starting state
Run the edge case described above and capture the actual response and destination state
Recover the record once, then check that recovery did not create unintended additional work

Your validation checklistThe intended edge case has an observable resultRecovery does not create unintended additional workThe PagerDuty owner has a documented recovery decision

0 of 3 checks marked by you

Illustrative workflow, not a preconfigured automation. Complete these checks in your own account.

Define success before launch

Inspect the data and the intended outcome separately. Connection status is only the first check.

Expected, not tested

Escalate a narrowly defined operational exception to PagerDuty

Inspect the alert or incident on the correct service and verify the intended escalation path. Test resolution of the same deduplication key in a controlled environment.

Documentation-based reference. This workflow has not been tested end to end. Use a record or event you control before enabling live activity.

Questions answered

Common decisions when connecting Unify and PagerDuty.

Should every qualified prospect trigger PagerDuty?

No. This proposed use case is limited to an agreed operational exception. The receiving service and escalation policy must match that exception.[3][4]

Limits & decisions

Check these boundaries before designing a live workflow around the connection.

Ordinary prospect qualification is not an incident. This pattern is only appropriate when the team has explicitly agreed to an operational escalation.[3][4]
The receiver and downstream logic are implementation work, not a hosted endpoint or installed connector supplied by this article.[3][4]

What the connection supports

Understand the connection, the data involved, and the behavior that matters for a Unify + PagerDuty workflow.

Connection flowVia intermediary

UnifyPlay webhook

Your receiverCredentials, mapping, and result tracking

PagerDutyDestination operation

Prospect handoff

Authenticated intake and destination API

Documented behavior at a glance
Decision	What to know
Unify action	Outbound HTTP request with configurable method, authentication, headers, and body[1]
Receiving operation	Create an Events API V2 integration on the intended service and obtain its routing key. Agree which exception warrants notifying the on-call team.[4]
Response handling	Webhook response bodies are not available as inputs to later Unify Play actions[2]

Technical setup reference

References and requirements for the PagerDuty connection.

Unify reference: Webhook action PagerDuty reference: official connection reference

Connection requirements and setup checklist

Before connecting

A Unify Play with a Webhook action and a controlled record for testing
Access to the intended PagerDuty environment and the permissions required by the cited API or trigger
An HTTPS receiver your team implements or configures, with an owner and a place to inspect accepted work
An agreed record identity, duplicate policy, and owner for failed handoffs

Prepare the PagerDuty destination
Create an Events API V2 integration on the intended service and obtain its routing key. Agree which exception warrants notifying the on-call team.[3][4]
Implement the receiving operation
Have the receiver build a PD-CEF event with routing_key, event_action: trigger, a stable dedup_key, and a payload containing summary, source, and severity. Store the identity needed to resolve the event later.[3][4]
Configure the Unify request
Use POST, the endpoint and authentication below, and JSON body format in the Webhook action. Replace setup placeholders, then inspect Expand preview with a controlled record. The receiver must respond within 8 seconds; webhook response bodies are not exposed to later Play steps.[1][2]
Validate the complete handoff
Run the success and edge-case scenarios in Explore the scenarios with a controlled record. Save the request identity and destination evidence, then apply the completion check before enabling live traffic.[3][4]

Request configuration

Method: POST
URL pattern: https://YOUR_RECEIVER_HOST/webhooks/unify/pagerduty
Headers: Content-Type: application/json
Authorization: Bearer YOUR_RECEIVER_SECRET
Authentication: Protect your own HTTPS receiver with a Bearer secret checked by your application. Keep the destination credentials in the receiver, not in this example payload.

Choose JSON as the body format. Unify sets Content-Type automatically. The receiver must respond within Unify’s 8-second timeout; request responses are not passed to later Play steps.[2]

Replace URL placeholders with the actual receiver URL from your account or deployed application. These example URLs are not working endpoints.

Example handoff payload

Start with a fictional prospect. Validate the resolved values before using a real record.

Inspect the sample payload and field mapping

Example request body

{
  "event": "prospect_handoff",
  "handoff_id": "example-handoff-001",
  "prospect_name": "Alex Morgan",
  "prospect_email": "alex@example.com",
  "company_name": "Example Company",
  "company_domain": "example.com"
}

Fictional data. Replace sample values before using a real Play.

Proposed JSON contract for your receiver, not a ready-made destination API request. Implement the translation in Technical setup. All prospect values are fictional and all setup placeholders must be replaced. Use the field mapping to distinguish record data from fixed settings. Select available fields in your Play and inspect Expand preview; do not replace configuration values with prospect data.[1][2][3][4]

Payload field	Value to send
`event`	string / static / Request configurationKeep the literal "prospect_handoff" required by this example request; change it only when deliberately changing the receiving contract. If missing: Keep this configured value in the request; do not replace it with a blank prospect field.
`handoff_id`	string / dynamic / Handoff identity chosen by your implementationSupply a stable identifier for this logical handoff. Reuse it on a retry, and use a different identifier for a genuinely new event. Do not assume Unify automatically creates this sample field. If missing: Hold the handoff until the receiver or upstream workflow can establish its identity.
`prospect_name`	string / dynamic / Full nameSelect the available full name field for the controlled person or company record in Unify. Keep the receiving field a string. If missing: Skip or hold the handoff if this value is required by the destination; omit it only when the destination contract permits omission. Do not send a guessed value.
`prospect_email`	string / dynamic / EmailSelect the available email field for the controlled person or company record in Unify. Keep the receiving field a string. If missing: Skip or hold the handoff if this value is required by the destination; omit it only when the destination contract permits omission. Do not send a guessed value.
`company_name`	string / dynamic / Company nameSelect the available company name field for the controlled person or company record in Unify. Keep the receiving field a string. If missing: Skip or hold the handoff if this value is required by the destination; omit it only when the destination contract permits omission. Do not send a guessed value.
`company_domain`	string / dynamic / Company domainSelect the available company domain field for the controlled person or company record in Unify. Keep the receiving field a string. If missing: Skip or hold the handoff if this value is required by the destination; omit it only when the destination contract permits omission. Do not send a guessed value.

Map only a genuine operational exception into the incident event. The sample receiver body is not the PagerDuty Events API schema; configure service routing and severity on the server.

Troubleshooting

Start with the stage where the expected data or action stops appearing.

The request is rejected

Protect your own HTTPS receiver with a Bearer secret checked by your application. Keep the destination credentials in the receiver, not in this example payload. Check the receiving account, permissions, endpoint, and required fields against the cited documentation.[3][4]

The values or destination are wrong

Compare the resolved JSON with the field-by-field contract in Example handoff payload. Check identifiers against the selected PagerDuty environment, and distinguish an absent source value from an intentional static value. Fix the mapping before repeating the write.[3][4]

Receipt does not match the expected result

Find the request in the receiving logs, then inspect the actual PagerDuty resource or execution. If the request was accepted but no result exists, investigate the destination failure before retrying. Keep the same logical handoff identity when recovering a repeat.[3][4]

Sources & review

Official documentation reviewed on September 15, 2026.

Technical claims link to primary documentation from Unify and the destination tool. Scenarios, field choices, and recovery plans are editorial implementation examples. Documentation review is separate from execution testing.

Documentation reviewed; end-to-end execution not tested. No named technical reviewer has signed off on these articles yet.

Content updated: 2026-09-16. Report a correction to Unify with the tool name, source URL, and behavior you observed.

How to integrate Unify with PagerDuty