Webhook Integration

OVERVIEW

Watchman Monitoring's webhook integration sends real-time notifications about plugin results, computer events, and group activity to any system that can accept an HTTPS POST. Use it to open and close tickets in your PSA, post alerts to Slack or Teams, or drive automations in Zapier, Make, or a tool you wrote yourself. You can configure multiple endpoints per company, each with its own event selection.

Webhooks are one-way: Watchman Monitoring sends data out. There is no webhook path back in. If your integration needs to write to Watchman Monitoring, use the public API or a natively integrated PSA.

WHAT ARE WEBHOOKS?

Webhooks are HTTP callbacks that send data from one application to another when specific events occur. Think of them as "reverse APIs" — instead of your tools asking Watchman Monitoring for data, Watchman Monitoring sends data to your tools when something happens.

WAYS MSPS CAN USE WEBHOOKS

Streamline operations

• Automated ticket creation: open a ticket in your PSA when a plugin enters Warning or Alert, and close it when the plugin clears
• Real-time notifications: instant Slack or Teams messages for urgent issues
• Workflow automation: connect to Zapier, Make, or IFTTT to trigger actions in hundreds of other applications
• Multiple system integration: send different event types to different systems simultaneously

Improve client communication

• Proactive alerts: notify clients when their systems have issues
• Status updates: keep clients informed about system health
• Custom reporting: feed a data warehouse, SIEM, or dashboard

HOW IT WORKS

1. Event detection. When a computer checks in, Watchman Monitoring compares each plugin's result to its previous result. A webhook fires on a change — for example, OK → Warning, or Alert → OK. Computer and group events fire when a new computer first reports, when a group is created, or when Beacon Service sees a computer go missing or come back.
2. Delivery. Watchman Monitoring builds a JSON payload and POSTs it to every enabled endpoint that subscribes to the event. Each endpoint receives one delivery per event, even when several of its selected event types apply to the same change.
3. Retries and logging. Failed deliveries are retried with exponential backoff, and every attempt is recorded on the endpoint's Deliveries page.
4. Integration processing. Your receiving system (Slack, PSA, automation tool) parses the JSON and takes action.

CHOOSING WHAT AN ENDPOINT RECEIVES

Each endpoint runs in one of two modes.

All events (recommended, and the default for new endpoints)

• Delivers every webhook event: new computers, new groups, Beacon online/offline, and every plugin severity change.
• Includes events for muted plugins and hidden computers, groups, and plugins. Every payload carries is_muted, mute_type, and is_hidden so you can filter downstream.
• Best for Zapier, Make, SIEM, data warehouses, and custom receivers — anywhere it is easier to filter on your side than to guess in advance which events you will want.

Specific events only

• Delivers only the event types you check.
• Respects Watchman Monitoring's mute and visibility rules, so muted plugins and hidden computers, groups, and plugins are skipped (with one exception, noted under Plugin cleared below).
• Best when a receiver should act on a narrow set of events — for example, Plugin alert / warning plus Plugin cleared to open and close PSA tickets.

SUPPORTED EVENT TYPES

Plugin severities, from least to most serious

• OK — no issue detected
• Informational — a noteworthy condition that is not a problem
• Warning — an issue has been detected
• Alert — a one-time alert has occurred (reboot, kernel panic, and similar)

Computer events

• Computer added (computer_added) — a new computer checks in to your account for the first time.
• Beacon status changed (computer_status_changed) — a computer went missing or came back online. Requires Beacon Service. If Beacon is not enabled for your company, this event never fires.

Plugin events

• Plugin alert / warning (plugin_alert) — a plugin enters Warning or Alert from a less serious state, for example OK → Warning or Warning → Alert. It does not fire on de-escalations (Alert → Warning) or on a plugin's first report. Skipped for muted plugins.
• Plugin status changed (plugin_status_changed) — any severity change, in either direction. This is a superset of Plugin alert / warning and Plugin cleared. Skipped for muted plugins.
• Plugin cleared (plugin_cleared) — a plugin returns to OK after being in Warning or Alert. Pair it with Plugin alert / warning for open-and-close ticketing. This event still fires for muted plugins — unless the plugin was muted by a ticket — so you are told when a muted issue resolves itself.

Group events

• Group created (group_created) — a new computer group is created. Skipped for hidden groups.

WHICH PLUGIN EVENT FIRES WHEN

Plugin webhooks fire on a change of severity. If a plugin reports the same severity twice in a row, nothing is sent.

When more than one of your selected event types applies to the same change, the endpoint receives a single delivery using the most specific match — plugin_alert or plugin_cleared in preference to plugin_status_changed. You will not get two messages for one transition.

The same table is built into the dashboard: open Settings → Webhooks, edit an endpoint, and click the help link to see the transition reference alongside your configuration.

WEBHOOK PAYLOADS

Every payload has the same envelope:

{
  "event_type": "plugin_alert",
  "event_id": "wm_evt_a1b2c3d4e5f67890",
  "timestamp": "2026-01-15T10:30:00Z",
  "subdomain": "acme",
  "data": { ... }
}

Plugin payloads carry the severity as a word, alongside the original integer fields:

• severity — ok, informational, warning, or alert
• previous_severity — the prior state on transition events
• status_code, previous_status, and new_status — the original integer fields (0 = ok, 20 = informational, 2 = warning, 200 = alert), still sent for backward compatibility
• is_muted, mute_type, and muted_until — mute state; mute_type is null, muted_forever, timed_mute, or ticket_mute
• is_hidden — true when the computer or plugin is hidden

Existing integrations that filter on status_code == 200 keep working. For new integrations, filter on severity == "alert" — it is easier to read in Zapier, Make, and log searches.

Test deliveries carry wm_test: true and an event_id beginning wm_test_, so your receiver can ignore or route them.

For the complete field reference, per-event examples, and retry details, see the webhooks section of the API documentation.

CONFIGURATION GUIDE

Step 1: Open webhook settings

1. Log in to your Watchman Monitoring dashboard.
2. Go to Settings → Webhooks (also linked from the Integrations page).
3. Click New Endpoint. You can configure several endpoints per company.

Step 2: Configure the endpoint

1. Name: something descriptive, such as "Slack — monitoring alerts" or "PSA — ticket automation".
2. Webhook URL: the HTTPS URL that will receive the POST. HTTP URLs are not accepted.
3. Events: choose All events, or Specific events only and check the events you want.
4. Save the endpoint.

Step 3: Test it

1. Open the saved endpoint. In All events mode, pick a sample event and click Send Test; in Specific events mode, click Send Test next to any event.
2. The test is queued through the same delivery pipeline as a real webhook, so it exercises your URL, TLS, and receiver exactly as production traffic will.
3. Open the Deliveries page for that endpoint and select the Test tab to see the result. Pending rows can be refreshed in place.

Use View Payload next to any event to see a sample body before you build against it.

Step 4: Monitor and maintain

• Check the Deliveries page after any change to your receiver. Success, failure, and total counts on that page cover real deliveries only; tests are counted separately.
• Delivery history is retained for 30 days.
• Update the URL if your receiving system changes, and remove endpoints you no longer use.

DELIVERY, RETRIES, AND FAILURES

• Timeouts: 10 seconds to connect, 30 seconds to respond.
• Success: any 2xx response. Anything else counts as a failure.
• Retries: roughly 2 minutes after the first failure, then 4, then 8, each with up to a minute of jitter.
• Pausing: after 3 consecutive failed deliveries (each with retries exhausted), the endpoint stops sending.
• Recovery: there is no manual re-enable button. Fix your receiver, then click Send Test — one successful delivery resets the counter and the endpoint resumes. Failed tests do not count against you.
• Idempotency: every delivery carries a unique event_id. Use it as your idempotency key if your receiver needs to de-duplicate.
• Ordering: two rapid transitions on the same plugin may arrive out of order. Use the timestamp field if order matters to you.

Rate limits

• 50 deliveries per minute per endpoint.
• 500 deliveries per hour per company, across all endpoints.

Events beyond those limits are not delivered, so prefer several purpose-built endpoints over one endpoint fed by unfiltered noise.

POPULAR MSP INTEGRATION SCENARIOS

1. Slack notifications

Create an Incoming Webhook in Slack and paste its URL into your endpoint. Watchman Monitoring detects Slack URLs automatically and formats messages with rich attachments and color coding — green for OK, yellow for warnings, red for alerts. Use a dedicated channel such as #monitoring-alerts.

2. PSA ticketing (ConnectWise, Autotask, Kaseya, and others)

Select Plugin alert / warning and Plugin cleared in Specific events mode, and point the endpoint at your PSA or at a Zapier/Make scenario in front of it. Open a ticket on the alert, resolve it on the clear, and match the two using computer_uid plus plugin_uuid.

3. Zapier or Make automation

Use All events mode with a "Webhooks by Zapier" (or Make webhook) trigger and filter inside the automation on event_type and severity. That way you do not have to revisit Watchman Monitoring every time you want to act on a different event.

4. Microsoft Teams

Create an Incoming Webhook connector for the channel and paste its URL. Teams receives the raw JSON, so most teams put a Power Automate flow or a small formatter in between.

5. Custom applications

Accept POSTs with a JSON body at an HTTPS URL, respond 2xx quickly, and process asynchronously. Treat the URL itself as a secret: anyone who has it can post to your receiver.

BEST PRACTICES

• Start with All events and filter in your integration. It is the most flexible setup and the one least likely to leave you wondering why an event never arrived.
• Use Specific events for narrow automations, such as ticket open/close, where a stray event would create work.
• Name endpoints by purpose — "Slack critical alerts", "PSA all events" — so the endpoints list stays readable.
• Respond fast. Acknowledge with a 2xx and do the slow work in the background; a receiver that takes longer than 30 seconds is treated as a failure.
• Handle duplicates and gaps. Retries mean the same event_id can arrive more than once, and a paused endpoint means events can be missed entirely.
• Keep URLs private, use HTTPS (required), and rotate the URL if it is ever exposed.
• Review deliveries periodically, not just when something breaks.

TROUBLESHOOTING: WHY DIDN'T MY WEBHOOK FIRE?

1. No prior state. The first report of a plugin does not fire a webhook — there is nothing to transition from. Deleting a plugin's history does not let you re-trigger it, for the same reason.
2. Unchanged severity. A plugin reporting Warning again after Warning is not a transition, so no webhook is sent.
3. Muted plugins. Muted plugins are skipped by Plugin alert / warning and Plugin status changed. Plugin cleared still fires unless the mute came from a ticket. All events mode always fires; check is_muted and mute_type in the payload.
4. Hidden computers, groups, and plugins. Skipped for every mode except All events.
5. Beacon not enabled. Beacon status changed only fires for companies using Beacon Service.
6. The endpoint is paused. Three consecutive failures stop delivery. Fix the receiver and send a test to resume.
7. Rate limits. 50 per minute per endpoint, 500 per hour per company.
8. Event not selected. In Specific events mode, confirm the event you expect is actually checked — or switch the endpoint to All events.

Other common issues

• Nothing arriving at all: confirm the URL is reachable from the public internet, accepts POST with a JSON body, and presents a valid TLS certificate. Then send a test and read the response recorded on the Deliveries page.
• Payload looks different than expected: fields with no value are omitted from the JSON, so write receivers that tolerate missing keys.
• Formatting: Slack URLs are formatted automatically; everything else receives raw JSON. Zapier or Make is the quickest way to reshape it.
• Test deliveries not in the list: they live under the Test tab on the Deliveries page, separate from real traffic.

GETTING HELP

• Check the Deliveries page for the endpoint — the response status and body from your server are recorded there.
• Review the webhooks API documentation for payload examples and the full field reference.
• Contact support at support@watchmanmonitoring.com if issues persist — include the endpoint name and the timestamp of a delivery that did not behave as expected.