Skip to content

Connections

A connection is a destination for your notifications: a named webhook URL. Rules point at a connection rather than carrying a URL of their own, so you can set a destination up once and reuse it across many rules - and change the URL in one place if it ever moves.

Find them under Webhook Notifier → Connections.

Creating a connection

  1. Go to Webhook Notifier → Connections → New.
  2. Give it a Name you'll recognise later, e.g. "Teams: #deploys" or "Slack: #sales-leads".
  3. Paste the Webhook URL, or a reference to an environment variable that holds it (see below).
  4. Save, then use Send a test to fire a test payload at it and confirm it arrives.

Keeping the URL secret

A webhook URL is a secret - anyone who has it can post to your channel. Webhook Notifier keeps it out of plain sight in two ways, and you can use either:

  • Stored encrypted. Paste the URL directly and it's encrypted before it's written to the database. It's decrypted only when a notification is sent.
  • Environment variable reference. Enter $YOUR_ENV_VAR (with the leading $) and the plugin resolves it at send time. The actual URL lives in your .env file, never in the database and never in project config.

The environment-variable approach is the tidier one for teams and for deploy pipelines: the URL can differ per environment (a test channel on staging, the real channel in production) without any database changes.

bash
# .env
TEAMS_DEPLOYS_WEBHOOK="https://prod-12.westeurope.logic.azure.com:443/workflows/..."

Then enter $TEAMS_DEPLOYS_WEBHOOK as the connection's URL.

Sending a test

The Send a test button on the connection posts a small sample payload to the URL straight away, without needing a rule. Use it whenever you add or change a connection - if the destination is going to reject the post (a Teams permissions problem, a wrong URL, an expired hook), you'll find out here rather than the first time a real event fires. The result is written to the delivery log like any other send, so you can open it to see the exact response.

The default connection

In Settings you can nominate a default connection. A rule that doesn't choose its own connection falls back to this one, which is handy when most of your rules go to the same place. A rule that does choose a connection always overrides the default.

Deleting a connection

Deleting a connection doesn't delete the rules that used it.

Deleting a connection leaves its rules stranded

Rules pointing at a deleted connection have nowhere left to send to. Check the Rules list afterwards and point them at another connection (or the default) if you want them to keep firing.

Digital help you can trust.