Skip to main content
Cato Networks webhooks have no fixed request body; you write the body in CMA. This page gives a body template that Flashduty parses. storyId (the Site Operations story ID) identifies one event: Flashduty triggers or updates the alert while the story is open, and recovers it when storyStatus becomes RESOLVED (or endDate is set).

In Flashduty On-call

Get the push URL in either of the following ways.

Use a dedicated integration

  1. In the Flashduty console, select Channel and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add integration
  3. Select Cato and click Save
  4. Open the generated integration card and copy the Push URL

Use a shared integration

  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select Cato and enter an integration name
  3. Configure the default route and choose a channel; you can add more rules under Routes later
  4. Click Save and copy the generated Push URL

In Cato

You need permission to manage Subscriptions in CMA.
1

Create a webhook in Cato CMA

Where: Cato CMA › Account › Subscriptions › Webhooks › New Webhook
2

Paste the body template

Where: Cato CMA › Account › Subscriptions › Webhooks › New Webhook › Custom Body › Edit BodySet the body to Custom and paste the template below. Cato replaces each ${field:} with the field value; the text after the colon is the default when the field has no value (empty here):
Field definitions: Understanding the JSON Fields for Alert Integrations. Keep storyId, correlationId, storyStatus and endDate; they decide how alerts are merged and recovered.
3

Subscribe and verify

Where: Cato CMA › Account › Subscriptions
  1. Under Account → Subscriptions, add this webhook as a delivery target for the alert types you want (Site Operations stories and so on). Recovery notifications must also be delivered to this webhook, otherwise alerts do not recover
  2. Click Test on the webhook page. Cato sends the test request with auto-generated content, and Test passed successfully only proves the connection works. The Cato documentation does not show the test request body, and Flashduty handles it as a normal alert: without storyId and correlationId it returns a parameter error, otherwise it opens a separate alert that you close manually after the check
  3. Trigger a real event (for example, disconnect the Socket of a test site), confirm Flashduty receives an active alert, then confirm it recovers when the story resolves
storyId exists only on Site Operations stories. Other alert types have no such field, so Flashduty uses correlationId as the Alert Key. Those alerts recover only when endDate is set; otherwise turn on auto-close in the receiving channel (24 hours suggested). Follow-up updates for the same story depend on Cato’s XOps correlation; without it, each notification may be a separate event.

Alert key

Flashduty uses storyId as the Alert Key, and correlationId when storyId is empty. Cato defines storyId as “Unique identifier for the Site Operations story” and correlationId as “Unique identifier used to correlate related events, messages, or operations”. Changes to title, level or time never change the Alert Key. A request with neither field is rejected with the field name.

Status and severity

An alert recovers when storyStatus is RESOLVED or endDate is not empty; other states such as OPEN and IN_PROGRESS trigger or update it. Severity comes from level:

Labels

Troubleshooting

  • Cato test fails: confirm the URL is complete, includes integration_key, and the method is POST
  • Flashduty returns a parameter error: confirm the body is valid JSON and contains storyId or correlationId. If a title or subject contains double quotes, Cato’s substitution may break the JSON; remove the title or subject field from the template
  • Alert does not recover: confirm the template keeps storyStatus and endDate, and that the resolution notification is also delivered to this webhook