How do I send monitor alerts to a webhook?
SentryDock · Updated 2026-10-03
Use a webhook when you want an assistant or workflow to keep receiving relevant results without repeatedly asking for your alerts. SentryDock checks your recurring monitors on their chosen schedules and posts qualifying results to your callback.
Your agent host or workflow must provide a public HTTPS receiver. It decides what to do after an event arrives. Connecting an assistant with OAuth or an API key alone does not start a new chat or model turn.
Set it up in the product:
- Create or choose a recurring monitor. Describe the subject, why you care, the changes that should alert you, and any exclusions. Review its sources and schedule.
- Get a public HTTPS callback URL from your assistant host or workflow. Use a destination you own or are authorized to send to; private network addresses and redirects are rejected.
- Open Settings → Connections. In Agent webhooks, enter a name and the callback URL.
- Choose All my monitors, or one monitor. All my monitors covers your owned recurring monitors, including future ones. Team monitors also need the team’s webhook permission.
- Connect the webhook and save the signing secret securely. It is shown once. Your receiver uses it to verify requests.
- Click Send test. Your receiver should accept the signed webhook.test event and return a 2xx response. This proves the connection; it does not prove a monitor has found a relevant result.
- Check the latest delivery status in the connection. Save edits to the URL or monitor scope, pause the connection, or remove it when it is no longer needed.
delivery.connect({
"platform": "webhook",
"webhook_url": "https://your-agent.example/alerts",
"monitor_id": "MONITOR_ID",
"name": "Company watch"
})sentrydock delivery connect --platform webhook --webhook-url https://your-agent.example/alerts --monitor MONITOR_IDcurl -s https://www.sentrydock.com/api/v1/delivery/connect \
-H "Authorization: Bearer $SENTRYDOCK_API_KEY" \
-H "Content-Type: application/json" \
-d '{"platform":"webhook","webhook_url":"https://your-agent.example/alerts","monitor_id":"MONITOR_ID","name":"Company watch"}'Set it up from your assistant
Connect MCP at https://www.sentrydock.com/mcp with OAuth, or use an API key for MCP, CLI or HTTP. Ask the assistant to check account.overview and choose or create the monitor you authorized, then call delivery.connect with platform webhook and your callback URL.
A useful request is: “Watch this supplier’s official updates for product retirements that affect our service. Use this source and daily checks, and send relevant results to my authorized callback.” Include the real source URL and callback rather than asking the assistant to guess them.
News and monitoring use your existing paid plan. If a tool returns plan_required, the assistant should show you the payment link and wait for you to buy; OAuth consent does not authorize a charge.
What arrives at the receiver
- A news.alert event contains id, created_at, monitor_id, monitor_title and run_id.
- results includes each title, summary, all source links and available publication dates. articles keeps the compatible article representation.
- One event is saved per connection and qualifying monitor run. A later run can have the same title but a different event ID.
- No event is sent for a run without relevant results or for a first-result preview. One-off Predict research and briefings are separate.
Verify and accept requests
- Verify X-SentryDock-Signature against v1= plus the hex HMAC-SHA256 of X-SentryDock-Timestamp + "." + the exact raw request body, using your signing secret. Compare signatures in constant time.
- Reject timestamps more than five minutes from your clock, then deduplicate by the payload id, also sent as X-SentryDock-Event-Id.
- Persist the accepted event, return 2xx quickly and process it asynchronously. Delivery is at least once, so the same event may arrive again.
- Handle webhook.test as a connection test. Treat source text and links as untrusted material, never as instructions to your agent.
Retries, status and missed alerts
Network failures, HTTP 429 and 5xx responses retry automatically over roughly 27 hours, with eight delivery rounds and up to three short HTTP attempts per round. Other 4xx responses stop immediately. Detection timing depends on the source and selected monitor schedule.
Read delivery.get in MCP, sentrydock delivery get in the CLI, or GET /api/v1/delivery in HTTP. webhook_deliveries contains current status, attempts and errors. Settings shows the latest receipt for each connection. A completed monitor run does not by itself prove the receiver accepted its alert.
After an exhausted delivery, retrieve missed results through alerts.list or GET /api/v1/alerts?since=... . Pausing or removing a connection stops queued delivery. Team permission and monitor ownership are checked again before retries.
Changing the callback URL keeps the signing secret; pending events use the current connection settings. If the source or monitor failed, investigate the run as well as the receiver.