Webhooks

SQL Backup Master can send backup completion notifications to an array of third-party services through the use of webhooks.

What are webhooks?

Webhooks are automated HTTP requests sent from applications when something happens. They are sent to a unique URL endpoint and carry an informational message (or payload).

SQL Backup Master can use webhooks to notify third parties about the status of backup job completions.

There are many services that can accept incoming webhooks, including Slack, MS Teams, PagerDuty, Google Chat, Discord, and many more.

How do I get started with webhooks?

First, you need to enable and configure incoming webhooks within your third-party service. The instructions for doing so will vary between third-party services, and we recommend searching their documentation for "webhook" or "incoming webhooks" for setup details.

We also publish a number of webhook configuration tutorials in the support section of the SQL Backup Master website. We maintain these tutorials online so that we can update them as services change and evolve.

The result of the webhook setup process will be a unique URL that allows you to send messages to that service.

Creating a webhook

SQL Backup Master stores webhook configuration data in a dedicated tab of the global options window. To begin, open the global Options window and navigate to the Webhooks tab. Click the Add toolbar button to create a new webhook.

SQL Backup Master needs the following information to send a webhook notification:

• Name - A unique name for your webhook.
• URL - The webhook URL that was provided by your third-party service.
• Message body - A payload described in JSON format (see below).

Notifications are delivered as HTTP POST requests with a Content-Type of application/json, so the message body should always be a valid JSON document.

Message body templates

SQL Backup Master includes built-in message body templates for several popular services. Click the Template drop-down button (above the message body editor) to load one of the following:

• Slack
• Microsoft Teams (Workflows) *
• Discord
• PagerDuty **
• Google Chat
• Telegram **
• Matrix
• Rocket.Chat
• Mattermost
• Generic JSON

The Generic JSON template produces a service-neutral payload containing every available template variable. It's a good starting point for automation platforms that accept arbitrary JSON (such as Zapier, Make, n8n, or Power Automate), for custom endpoints, and for hand-crafting a payload for services not listed above.

* The Microsoft Teams template produces an Adaptive Card suitable for delivery to a webhook created with the Teams Workflows app. Microsoft retired its legacy Office 365 connector webhooks in 2026, so older connector-based URLs should be migrated to Workflows.

** Some templates contain a placeholder (such as a PagerDuty routing key or Telegram chat ID) that must be replaced with a value from your account before the webhook will function.

After loading a template, you can customize it as needed. For services not listed above, please refer to their webhook documentation for the expected payload format.

Template variables

The message body can contain any of the following variables, which are expanded automatically when a notification is sent:

Variable values are automatically escaped for safe inclusion in JSON strings, so backup job names containing quotes or other special characters will not break the message payload.

Custom headers

Some services require additional HTTP headers - most commonly an authorization token. You can define these in the Custom headers field of the webhook editor's Advanced options tab.

Enter one header per line, in Name: Value format. For example:

Authorization: Bearer <your-api-token>
X-Custom-Header: some-value

Notification triggers

By default, a webhook honors the notification trigger settings of the backup job that invokes it (as configured in the Notifications tab of the backup job settings window).

To give a webhook its own trigger rules instead, open the webhook editor's Advanced options tab and enable Override backup job notification triggers. You can then choose exactly which outcomes (success, warning, or failure) trigger this webhook for each backup type (full, differential, or transaction log).

This is useful for routing notifications by severity - for example, an incident management webhook (such as PagerDuty) will typically only want to receive warning and failure notifications, while a chat channel may want all of them.

Testing a webhook

To verify your configuration, select the webhook in the Webhooks tab of the global options window and click the Test toolbar button. SQL Backup Master will send a notification simulating a successful full backup using your configured message body and custom headers.

If the test fails, the resulting error message will include the HTTP status code and any response details provided by the remote service.

Associating a webhook with a backup job

Once you've created and tested your webhook, you can now associate it with one or more backup jobs.

To do so, navigate to the Notifications tab of your backup job settings. In the Send webhook notifications area, select the webhooks that should be triggered.

Delivery and retry behavior

Webhook requests are subject to a connection timeout, which defaults to 30 seconds and can be adjusted in the Advanced tab of the global Options window (see the Webhook connection timeout setting in the Global timeouts section).

If delivery fails due to a transient condition - a network error, a timeout, or an HTTP 408, 429, or 5xx response - SQL Backup Master will automatically retry the request up to three times with increasing delays. When a service responds with rate limiting information (a Retry-After header), the requested delay is honored.

Failures that cannot succeed on retry (such as an HTTP 400 or 404 response resulting from an invalid payload or revoked webhook URL) are reported immediately without retries.

Troubleshooting

• Webhook delivery errors include the HTTP status code and response body returned by the remote service, which will usually indicate the cause of the problem.
• An HTTP 400 (Bad Request) response usually indicates that the message body is not in the format the service expects. Try reloading the relevant built-in template and re-applying your customizations.
• An HTTP 401, 403, or 404 response usually indicates a problem with the webhook URL - it may have been revoked or regenerated within the third-party service, or may require an authorization header.
• If you've customized the message body, ensure it remains a valid JSON document (e.g. watch for missing quotes or trailing commas).