Notification channels

All endpoints require the notifications scope. Channels created via API behave exactly like console-created ones: select them on links, and they deliver with the same signing, retries and delivery log.

List channels

GET /v1/channels

curl https://api.neon.xengo.io/v1/channels \
  -H "Authorization: Bearer $XENGO_API_KEY"

{
  "channels": [
    {
      "id": "4a0da012e0f56677",
      "type": "webhook",
      "name": "Ops endpoint",
      "enabled": true,
      "signed": true,
      "confirmed": true,
      "sentCount": 231
    }
  ]
}

Create a channel

POST /v1/channels

curl -X POST https://api.neon.xengo.io/v1/channels \
  -H "Authorization: Bearer $XENGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "webhook",
    "name": "Ops endpoint",
    "config": { "url": "https://ops.acme.com/hooks/xengo" }
  }'

{
  "id": "9b1c22f4a7d81c02",
  "type": "webhook",
  "name": "Ops endpoint",
  "enabled": true,
  "signed": true,
  "signingSecret": "whsec_9xJd…"
}

Each channel type has its own config shape — webhookUrl for Slack/Zapier/Make/n8n-style channels, address for email, routingKey for PagerDuty, and so on. Email channels start unconfirmed and deliver only after the recipient clicks the emailed opt-in link ("confirmed": false until then).

Delete a channel

DELETE /v1/channels/{id}

Links that referenced the channel simply stop alerting through it — the links themselves are untouched.