Skip to main content
Use an Aikido Security webhook to send security issues to Flashduty On-call. Each Aikido issue maps to one Flashduty alert. When the issue is created, changes severity, is closed, ignored, or snoozed, the same alert is updated or recovered.

​
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 Channels and open a channel
  2. Select Settings → Integrations → Dedicated integrations, and click Add an integration
  3. Select Aikido and click Save
  4. Open the generated integration card and copy the push URL

​
Use a shared integration

  1. In the Flashduty console, select Integration Center → Alert Events
  2. Select Aikido and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routes after creation
  4. Click Save and copy the generated push URL

​
Configure in Aikido

1

Create the webhook

A workspace admin configures webhooks in Aikido under Settings → Integrations → Webhooks. Set the target URL to the full Flashduty push URL (including integration_key) and select the events to send.
2

Select events

Select these issue events:
  • issue.open.created: a new issue, creates an alert
  • issue.severity.changed.manual, issue.sla.breached, issue.unignored: update the same alert
  • issue.closed, issue.ignored.manual, issue.snoozed: recover the same alert
Other events such as ci.gate.*, zen.*, and scan.image.finished carry no issue information. Flashduty returns 200 and ignores them without creating an alert.
3

Webhook secret (optional)

On the Webhooks page, click Add secret to generate a signing secret. Aikido then sends an HMAC-SHA256 signature of the payload in the X-Aikido-Webhook-Signature header. Flashduty does not verify this signature and does not need the secret. Pushing works with or without a secret.
4

Verify the lifecycle

Let Aikido raise a new issue and confirm the alert reaches Flashduty. Then close that issue in Aikido and confirm the original alert recovers. Aikido’s documentation does not describe a test notification button.

​
Alert Key

Flashduty uses payload.issue_id as the Alert Key. Aikido’s documentation defines it as the ID of the issue, and every event for the same issue carries it. Changes to severity, status, or event type do not change the Alert Key. An issue event without payload.issue_id is rejected, because later updates and recovery could not be matched to the alert.

​
Status and severity

The Aikido payload has no title field, so the alert title looks like Aikido open_source issue #123 (critical). The issue type (open_source, leaked_secret, cloud, iac, sast, surface_monitoring, malware), severity_score, and workspace_id are stored as alert labels.

​
Troubleshooting

  • Aikido gets a non-200 response and retries: Aikido retries 5 times on a non-200 response or a timeout. Confirm the push URL is complete and includes integration_key
  • Flashduty returns a parameter error: confirm the body is valid JSON and issue events carry payload.issue_id
  • The alert does not recover: confirm you selected recovery events such as issue.closed. Ignored and snoozed issues also recover the alert
  • CI or Zen events do not arrive: they carry no issue information and are ignored by design
  • Source IPs: Aikido sends from fixed addresses (EU 52.18.113.172, US 54.225.143.47 and 3.211.221.73, AU 52.65.15.49) if you need to allow them on your network
For field details, see Aikido Webhooks and Aikido webhook setup.