Send a small JSON message to any address you choose whenever an email fails, to feed monitoring, incident or automation tools.

The generic webhook sends a short JSON message to an address of your choice each time CRM-NG SMTP fails to send an email. This article describes exactly what is sent and how to connect it to other tools. It is for developers and operations teams who want email failures to reach a monitoring system, an incident tool or an automation service such as Zapier, Make or n8n.

Set it up

1. Get a receiving address

   In the tool that should receive alerts, create an incoming webhook or HTTP trigger and copy its URL. It must start with https:// and be reachable from the internet.

2. Open the Alerts tab

   Go to CRM-NG SMTP → Settings → Alerts.

3. Paste the URL

   Paste it into Generic webhook URL. The help text says it Receives a JSON POST containing site, subject, and error.

4. Save

   Press Save Alert Settings.

After saving, the box shows Saved — leave blank to keep. The URL is stored encrypted. Paste a new address to replace it, or leave the box blank to keep the current one.

What is sent

For every failed email, CRM-NG SMTP sends one HTTP POST request with the header Content-Type: application/json and a body like this:

{
  "site": "https://www.example.com",
  "subject": "Your order #1042 has shipped",
  "error": "Mailer: SendGrid\r\nThe provided authorization grant is invalid, expired, or revoked"
}

Field	Contents
site	Your site's home address, so you can tell sites apart if several report to the same place
subject	The subject line of the email that failed
error	The error text recorded for the failure, usually starting with the mailer's name

The recipient's address and the message body are not included.

How it behaves

• One request per failure. A mail outage on a busy site sends many requests. Your receiver should cope with bursts, or group alerts by site and error.
• Fire and forget. The request is sent in the background with a 5-second limit. CRM-NG SMTP does not wait for an answer, does not retry, and does not record whether your receiver accepted it.
• Never slows your site. Because it runs in the background, a slow or broken receiver does not delay the page that sent the email.
• Same rules as other alerts. Emails rescued by the backup SMTP transport, or blocked by Do Not Send, do not trigger a request. See Email failure alerts.

Securing the receiver

The request does not carry a signature or a secret header. Protect your receiver in other ways:

• Use a long, unguessable URL. Most tools generate one for you.
• If your tool supports it, put a secret token in the URL's query string and check it on arrival, for example https://hooks.example.net/email-alerts?token=….
• Only accept POST requests with a JSON body that has the three fields above.

Ideas for using it

• Incident tools. Many on-call services accept a JSON webhook and open an incident from it. Map subject and error into the incident title and details.
• Automation services. In Zapier, Make or n8n, use a "catch webhook" trigger, then post to a chat tool, create a help-desk ticket, or add a row to a spreadsheet.
• Your own script. A few lines of code on another server can log failures, count them, and alert only when there are more than a set number in an hour.

Test it

On a staging site, or at a quiet time, put a wrong key or password into your mailer settings on the General tab, then send a test from Tools → Email Test. Check that your receiver got the request. Then restore the correct settings.

If nothing arrives, check that the address is public and uses HTTPS, and that your host allows outbound HTTPS requests to it.

Related

• Email failure alerts
• Slack alerts
• Delivery and bounce webhooks
• Debugging sending issues