---
title: Connector configuration
description: This guide presents the connector configuration for the PagerDuty destination type, including the service-key and bi-directional paths.
url: https://coralogix.com/docs/user-guides/notification-center/destination-types/pagerduty/connector-config/
product: notifications
feature: Notification Center
feature_id: notification-center
feature_identifier: notifications/notification-center
last_updated: '2026-10-23'
---

# Connector configuration

The PagerDuty connector has two paths. Select one when you create the connector.

| Path               | Credential                                       | Sync                             | Sends            | Use it for                                                                                      |
| ------------------ | ------------------------------------------------ | -------------------------------- | ---------------- | ----------------------------------------------------------------------------------------------- |
| **Service key**    | Service integration key entered on the connector | One-way (Coralogix to PagerDuty) | Alerts and Cases | Routing notifications to a single PagerDuty service                                             |
| **Bi-directional** | Account-level PagerDuty integration              | Two-way (Cases ↔ PagerDuty)      | Cases only       | Keeping Cases and incidents in sync across acknowledge, resolve, comments, and resolution notes |

The connector path stays fixed after you create it. For what two-way sync covers and how to set up the account-level integration, see the [PagerDuty Bi-directional integration](https://coralogix.com/docs/integrations/pull/pagerduty.md).

* Service key
* Bi-directional

The service-key path sends notifications one way to a single PagerDuty service.

| UI label                | API field name          | Type     | Required | Allows notification source type overrides | Description                                                                                                                                                                                                        |
| ----------------------- | ----------------------- | -------- | -------- | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Service key**         | `integrationKey`        | `String` | true     | true                                      | Also known as an [Integration Key](https://support.pagerduty.com/main/docs/services-and-integrations#generate-a-new-integration-key), this unique identifier routes notifications to a specific PagerDuty service. |
| **Dynamic service key** | `dynamicintegrationKey` | `String` | false    | true                                      | Specify a dynamic, data-driven value for the service key using alert metadata. Useful if you need to route alerts to different PagerDuty services based on different conditions.                                   |

### Templating for dynamic routing

The **Service key** field supports [dynamic templating](https://coralogix.com/docs/user-guides/notification-center/dynamic-templating.md), which routes events to different PagerDuty services by inserting variables into the notification configuration based on their attributes.

Here is an example **Dynamic service key** configuration:

```
{% if alert.groups['team_name'] == 'alpha'%}

  930aaaaaaaaaaaaaaaaaaaaaaaaaa0d1

{% elif alert.groups['team_name'] == 'beta' %}

  930bbbbbbbbbbbbbbbbbbbbbbbbbb0d1

{% else %}

  930xxxxxxxxxxxxxxxxxxxxxxxxxx0d1

{% endif %}
```

The bi-directional path keeps a Case and its linked PagerDuty incident in sync in both directions. It reads an account-level PagerDuty integration and applies to Cases only, not to alerts.

| Field                     | Description                                                                                                                                                                                 |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **PagerDuty integration** | The account-level PagerDuty integration this connector uses for bi-directional sync. If none exists, the empty state links you to set one up.                                               |
| **Service name**          | Select the PagerDuty service this connector targets. Picking from the list stores that service's ID.                                                                                        |
| **Dynamic service name**  | (Advanced, optional) Dynamically target a PagerDuty service using templating. When set, it overrides **Service name**. Your template must produce the service **ID**, not the service name. |

Dynamic service name takes an ID

Despite the field name, **Dynamic service name** resolves to the same stored value as **Service name**, which is the service's ID. A template that produces a display name such as `payments-production` does not match a service, and notifications are not delivered.

Find the ID in PagerDuty: open the service, and take the last path segment of its URL, for example `PXXXXXX` in `.../service-directory/PXXXXXX`.

```
{% if cases.indicators.alerts[0].grouping['team_name'] == 'alpha' %}

  PAAAAAA

{% else %}

  PDEFAULT

{% endif %}
```

Before you select this path, add the account-level PagerDuty integration. For setup and the full sync behavior, see the [PagerDuty Bi-directional integration](https://coralogix.com/docs/integrations/pull/pagerduty.md).

## Next steps

Define the payload structure for PagerDuty notifications in [Message configuration](https://coralogix.com/docs/user-guides/notification-center/destination-types/pagerduty/schema-structure.md).