Integrations

An integration is a stored credential or webhook URL connecting Site Qwality to an external service. Once an integration exists, you can create notification channels that deliver to it. One integration feeds many channels: connect a Slack workspace once, then point channels at #ops, #deploys and #alerts-billing without connecting it again.

To let an AI assistant such as Claude or ChatGPT work with your account instead, see Connect AI assistants (MCP).

Chat and messaging

Slack OAuth-installed app. Posts monitor alerts to any channel.

Microsoft Teams Workflows webhook URL for a Teams channel. Posts Adaptive Cards.

Discord Incoming webhook URL from a Discord channel. Posts embeds.

Telegram Bot-based via setup-code flow. Direct messages or group chats.

Google Chat Incoming webhook URL for a space. Posts card messages.

Mattermost Incoming webhook URL, self-hosted or Cloud. Posts Slack-style attachments.

On-call and paging

PagerDuty Events API v2. Outages trigger an incident; recoveries resolve the same incident automatically.

Jira Service Management (Opsgenie) Opsgenie Alerts API. Outages create an alert; recoveries close it automatically by alias.

Push to your devices

Pushover User key plus an application token. Outages arrive at high priority.

Pushbullet Account access token. Note pushes to every signed-in device.

Anything else

Webhooks Signed JSON POSTs to your own URL, with retries and a delivery log.

Receive alerts from other tools

Alert sources Alertmanager, Grafana, CloudWatch, Datadog, Sentry, PagerDuty Events API v2, any JSON webhook or email open and resolve incidents.

Some alert sources (heartbeat monitors, TLS certificate alerts, page-speed alerts, DNS record changes) reach only some channel types, and a channel of a type the source does not support is skipped. See which alerts reach which channels.

How integrations and channels relate

1. Connect the integration once.
2. In a notification group, create a notification channel that references that integration, with any per-channel detail (such as the Slack channel, or the PagerDuty severity).
3. Attach the group to your monitors.

Right after you connect an integration, the dashboard does steps 2 and 3 for you: choose a group or create one, choose which monitors alert it (the ones that already do, every monitor, or ones you pick), then send a test. Skip for now leaves the integration unrouted, and its card says Not receiving alerts until a group, a service or an on-call contact method sends to it. Route alerts on the card opens the same step.

Through the API, one call does the same. It needs an admin or the integrations:manage scope:

curl -X POST https://api.siteqwality.com/v1/integrations/<integration-id>/routes \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "group": { "name": "Ops alerts" },
    "monitors": "all"
  }'

• group: {"id": "<group-id>"} for one of your groups, or {"name": "..."} to create one.
• monitors: "group" (the default) leaves monitors as they are, "all" adds the group to every monitor, or pass a list of up to 1,000 monitor ids.
• slack_channel: for Slack, the channel to post to, such as #ops-alerts. Other types refuse it.

It answers 201 with notification_group_id, notification_id, group_created and monitors_attached (the monitors that did not alert the group before). It answers 409 when the group already sends to the integration (for Slack, to that channel) or a group or account channel limit is reached, and 422 for a group or monitor that is not in your account. Nothing changes when it refuses. The integration list (GET /integration) marks an integration nothing sends to with "routed": false.

Read and change them over the API

The /v1 API serves integrations, notification channels and notification groups with one list shape and one error format:

Resource	Routes
Integrations	GET /v1/integrations, and GET, PATCH and DELETE on /v1/integrations/{id}
Channels	GET and POST /v1/notifications, and GET, PATCH and DELETE on /v1/notifications/{id}
Groups	GET and POST /v1/notification-groups, and GET, PATCH and DELETE on /v1/notification-groups/{id}

curl "https://api.siteqwality.com/v1/notification-groups?limit=50" \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY"

• Lists come newest first as {"data": [...], "next_cursor": "..."}. Send next_cursor back as cursor for the next page; it is null on the last page. limit is 1 to 200, 50 by default.
• A group comes with its channels. Channels and integrations carry their delivery health.
• PATCH takes the fields that create takes. A field you leave out keeps its value, and a field you send replaces it.
• DELETE answers 204, also when the item is already gone. Deleting an integration that channels, groups or services still use answers 409 unless you add ?force=true.
• Errors are application/problem+json with type, title, status and detail.
• The OpenAPI document for the whole API, /v1 included, is at https://api.siteqwality.com/v1/openapi.json. It needs no key.
• Reads need read:notifications, channel and group changes write:notifications, and integration changes integrations:manage.

Retry a write safely

Send an Idempotency-Key header (1 to 255 visible ASCII characters, such as a UUID) on any /v1 POST or PATCH, and a retry with the same key and the same request runs at most once:

curl -X POST https://api.siteqwality.com/v1/notification-groups \
  -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 6f1d2c3a-6b0e-4d3c-9a51-2c8f0e7b4d19" \
  -d '{"friendly_name": "Ops alerts"}'

• A repeat after the first one finished gets the first response again, with Idempotent-Replayed: true. Refusals such as a 400 are kept too, so change the key when you fix the request.
• A repeat while the first is still running answers 409 (idempotency_key_in_use); retry a moment later.
• The same key with a different method, path or body answers 422 (idempotency_key_reused).
• A 5xx or 429 is not kept: a retry with the same key runs again.
• Keys are kept for 24 hours per API key, API client or user.
• Responses that show a secret once (rolling an API key, rotating a webhook signing secret) are never stored. A repeat answers 409 (secret_not_replayable) with the id, so roll again if you lost the secret.

Who can change integrations

Each integration holds a credential, so only account admins can add, change or remove one. Members, auditors and viewers can see them.

API keys and API clients need the integrations:manage scope for those changes; write:notifications does not cover them. An API key with no scope list is unrestricted. AI assistants that sign in with OAuth are never offered the scope.

Credentials never read back in full. GET /integration shows a webhook URL as its scheme and host, such as https://discord.com/****, and a key or token as **** followed by its last four characters (just **** when it is shorter than 16 characters). To change a credential, choose Edit (Settings for a webhook) in the integration’s ⋯ menu and enter the new one. Slack reconnects with Add to Slack instead.

What a save checks

• A name is 1 to 256 characters.
• Every URL uses https and a public host. Discord, Google Chat and Microsoft Teams URLs must be on that service’s own webhook host, and Teams accepts Workflows URLs only.
• A notification channel must name an integration of its own type in your account.

See also

Notification channels The next step after connecting an integration.

Notifications overview Channels, groups, contact methods, rules.