Skip to main content
The Imperva (Thales) Cloud Application and Network Security console has Webhook Connections: set a notification policy’s delivery channel to a webhook and Imperva POSTs a fixed JSON payload to that URL. Once connected to Flashduty On-call, website DDoS, IP range DDoS, and single-IP DDoS start and stop events, and BGP connection down and up events, merge into one alert per object and resolve automatically.

In Flashduty On-call

You can get the integration 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 Imperva 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 Imperva and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routing after creation
  4. Click Save and copy the generated Push URL

Configure Imperva

1

Add a Webhook Connection

Where: my.imperva.com › Account › Account Management › Webhook Connections › Add WebhookClick Test Webhook to confirm the URL is reachable, then save.Configuring webhooks needs the Manage notification settings permission; viewing them needs View notification settings.
2

Select the webhook in notification policies

Add or edit a notification policy and choose the new Webhook Connection in Recipients → Channel. Create a policy for each notification subtype in the “Events and recovery” table below (Website DDoS, Website Group DDoS, Individual IP Protection, Network Protection, Network Connectivity).
3

Verify

Where: my.imperva.com › Account › Account Management › Webhook ConnectionsClick Test Webhook on the connection. Flashduty creates an Info alert titled like Hello World Test - <webhook name>. The test has no recovery notification, so close it by hand.Test Webhook sends a fixed HelloWorldTest sample, so it only proves the URL is reachable and the payload is parsed. A real alert needs a DDoS or BGP event covered by the notification policy; when the matching end event arrives, the alert for the same object recovers.
Imperva’s webhook payload has a fixed format and cannot be templated. Imperva may deliver the same event more than once; Flashduty merges repeats under the same Alert Key, so no duplicate alerts appear.

Events and recovery

  • The Imperva payload has no severity field, so severity comes from the event type. DDoS start events mean Imperva is blocking or diverting the attack, so they map to Warning. A BGP connection down and an attack alert that needs manual confirmation map to Critical
  • An end event (...Stop, BgpUp, PerformanceRestored) resolves the alert for the same object
  • MonitoringAttackStartCritical and TrafficStartDivert have no end notification, so each event opens its own alert. Turn on the channel’s auto-resolve timeout (24 hours suggested)
  • Other notification types (account, site, billing, subscription, policy changes, range status changes) create no alert; Flashduty acknowledges them and returns success

Alert key

The Alert Key is computed from the event family, the Imperva account ID, and the object identity. Start and end events read the same fields: The title, the account name in the payload, and the webhook ID do not take part. The event time event_metadata.event_date takes part only for the two one-shot event types above; paired start/end events do not use it. A redelivery of the same event carries the same event_date, so it still merges into one alert. A request without event_type, or without the object identity of its family, is rejected with an error that names the missing field.

Labels

The alert title comes from event_title and the description from event_details.event_body.

Troubleshooting

  • Test Webhook fails: Imperva requires the receiver to answer 200 or 201. Check that the push URL is complete, the integration_key is valid, and the integration type is Imperva
  • No alerts arrive: check that the notification policy’s Recipients use this Webhook Connection and that the event type is in the table above. Event types outside the table create no alert
  • An alert never resolves: check that the notification subtype of the end event is also in a notification policy. MonitoringAttackStartCritical and TrafficStartDivert never resolve automatically
  • A 400 response: the request lacks event_type or the object identity field; the response names the field
For more, see the Imperva Webhook Connections documentation.