A connector is an integration instance within a destination type that links Coralogix to a third-party service such as Slack, PagerDuty, or a Generic HTTPS endpoint. Each connector defines how notifications are sent, including authentication details, destination configuration, and optional dynamic routing fields. ## Understand connector configuration A connector configuration contains the parameters required to communicate with a destination type. These fields differ by destination and follow the vendor's specification. Connector configurations can include: - Authentication details such as keys or tokens - Endpoints such as API URLs or channels - Headers and body fields for HTTP-based connectors - Dynamic fields that use templates for data-driven routing Each destination type defines its own connector configuration schema. See the following configuration guides: - [Generic HTTPS connector](https://coralogix.com/docs/user-guides/notification-center/destination-types/https/connector-config/index.md) - [PagerDuty connector](https://coralogix.com/docs/user-guides/notification-center/destination-types/pagerduty/connector-config/index.md) - [Slack connector](https://coralogix.com/docs/user-guides/notification-center/destination-types/slack/connector-config/index.md) ## Use dynamic fields for data-driven routing Connectors can include dynamic fields that support templating. Dynamic fields let you route notifications based on alert or case data without duplicating connectors for each team, environment, or service. Templates use the Tera templating language. See [Dynamic templating](https://coralogix.com/docs/user-guides/notification-center/dynamic-templating/index.md) for syntax and examples. ## Create a connector Follow this procedure to create and configure a connector for any supported destination type, such as Slack, PagerDuty, or Generic HTTPS. 1. Select **Integrations**, then **Notification Center**, then **Connectors**. 1. Select **New connector** and choose a destination type. The setup fields vary by destination type: - **Slack**: sends notifications to Slack channels - **PagerDuty**: sends notifications to PagerDuty services - **Generic HTTPS**: sends notifications to a custom HTTPS endpoint 1. In the **Details** section, enter connector details: - **Name**: enter a descriptive connector name - **Description**: add context or usage information 1. In the **Configuration** section, define how Notification Center connects to the destination. Depending on the connector type, enter: - **Slack** - **Integration**: select a Slack integration previously created in **Integrations** - **Channel**: enter the default Slack channel to receive notifications, for example `my-alerts` - **PagerDuty** - **Service key**: enter the PagerDuty Events API v2 integration key for the service that receives alerts - **Generic HTTPS** - **URL**: enter the target HTTPS endpoint, for example `https://api.example.com/v1/resources/` - **Request type**: select the HTTP method used to send notifications: - **POST:** Sends notification data in the request body. Use when your endpoint expects structured payloads such as JSON. - **PUT:** Sends notification data in the request body using the PUT method. Use when your endpoint updates or replaces an existing resource. - **GET:** Sends notifications as an HTTP GET request without a request body. Use for compatibility with endpoints that follow legacy webhook behavior. When **GET** is selected, the connector sends notifications without a request body. Body-related configuration options are not available for this request type. Select **Send test notification** to validate the connector. 1. (Optional) Enable diagnostic logging. Turn on **Diagnostic logs** to write delivery failure logs for this connector to the `notification.deliveries` dataset. Ensure that this dataset has write permissions in **Dataset management**. 1. (Optional) Expand **Advanced settings** to define dynamic field behavior for alert-based notifications: - **Slack** - **Dynamic channel**: enter a Tera expression that overrides the static **Channel** at send time. Example: ```text {% if alert.groups["team_name"] %} {{ alert.groups["team_name"] }}-ops {% else %} general-ops {% endif %} ``` - **Fallback channel**: define a default channel used if the dynamic expression returns an empty value. - **PagerDuty** - **Dynamic service key**: enter a Tera expression that overrides the **Service key**. Example: ```text {% if alert.groups['team_name'] == 'alpha' %} 930aaaaaaaaaaaaaaaaaaaaaaaaaa0d1 {% elif alert.groups['team_name'] == 'beta' %} 930bbbbbbbbbbbbbbbbbbbbbbbbbb0d1 {% else %} 930xxxxxxxxxxxxxxxxxxxxxxxxxx0d1 {% endif %} ``` - **Generic HTTPS** - Dynamic fields are not available for this connector type. 1. Select **Create connector** to save the configuration. ## Result The connector appears in the **Connectors** list and becomes available for use in **Presets** and **Routing rules**. If diagnostic logging is enabled, delivery status and failure information are written to the `notification.deliveries` dataset. ## Manage existing connectors Manage all configured connectors from the **Connectors** tab in Notification Center. Each connector shows its name, description, and last update date. Available actions: - **View** a connector's details by selecting its name - **Edit** an existing connector's settings - **Duplicate** a connector to reuse its configuration - **Delete** connectors that are no longer needed - **Send test notification** to confirm delivery Note Dynamic fields are ignored for test notifications. ## Check required permissions Connector management actions require specific permissions. See roles and permissions: ## Next steps Review the configuration options for each supported third-party service in [Destination types](https://coralogix.com/docs/user-guides/notification-center/destination-types/introduction/index.md).