How it works

Webhook Notifier is built around three things: connections, sources, and rules. A rule ties the other two together.

The three pieces

Connections - where a notification goes

A connection is a named destination: a webhook URL and nothing more. You might have one for a #deploys Teams channel, another for a Slack channel, and a third for a Zapier catch hook. Connections are stored encrypted, or as a reference to an environment variable, so the URL never sits in plain text in your database or version control. See Connections.

Sources - what triggers a notification

A source is something that fires events the plugin can act on: an entry being saved, a user registering, a form being submitted, a queue job failing, the queue growing too large, or any Craft/Yii event you name yourself. Each source hands the rules engine a context - a bag of values about what just happened, which your payload can reference. See Sources.

Rules - the "when this, send that"

A rule is where it all comes together:

1. Pick a source (the trigger).
2. Add optional conditions to narrow it down (e.g. only the news section, or only when the queue is over 50).
3. Choose the connection to send to.
4. Build the payload - a Teams Adaptive Card, or a raw body of your own.

When the source fires and the conditions pass, the rule's payload is rendered against the event's context and delivered to the connection. See Rules.

What happens when a rule fires

1. A source fires. An entry is saved, a form is submitted, an event you named is triggered, and so on. The source builds a context describing it.
2. Rules are matched. Every enabled rule for that source is checked against its conditions. Rules whose conditions don't pass are skipped.
3. The payload is rendered. For a matching rule, the card or raw payload is rendered as a Twig template against the context, so {title} becomes the entry title, {fields.email} becomes the submitted email, and so on.
4. It's queued. The rendered payload is handed to a background job rather than sent inline, so a slow or unreachable webhook never holds up the request that triggered it.
5. It's delivered and logged. The job POSTs to the connection's URL. Success or failure, the attempt is written to the delivery log with the payload, the response, and the status. Failures are retried a few times before giving up.

Instant vs scheduled

Most sources are instant - they hook into a Craft or Yii event and fire the moment it happens. There's no polling and no cron in the loop.

One source, Queue size, is scheduled: it can't react to an event because "the queue is too big" isn't an event, so you run a console command from cron and it checks the current size each time. See Scheduled monitoring.

Reliable delivery

Because delivery is queued and retried, a rule doesn't depend on the destination being up at the exact moment the trigger fires. If a webhook is briefly unreachable, the job retries (up to your Max retries setting) with Craft's normal queue back-off. Every attempt lands in the delivery log, so you can always see what was sent and what came back - and resend it if you need to.

Nothing is sent until a rule says so

Installing the plugin doesn't send anything on its own, and neither does creating a connection. A source firing only matters once an enabled rule points it at a destination.