Skip to main content
You can configure workflows in incident.io to send HTTP webhooks. This allows you to notify external systems or services when an incident matches your criteria — using a custom payload, headers, and method. This step is useful for:
  • Syncing incident data with third-party tools
  • Triggering external automations
  • Creating integrations that aren’t yet supported natively

​
How to Set Up the “Send a webhook” Step

  1. Add the Step: Add a “Send a webhook” step to any workflow. This step can be placed after any condition you define, like when an incident is created or when the status changes.
  2. Configure the Webhook:
  • Endpoint URL: The destination URL where the webhook should be sent. This must be publicly accessible. Example: https://eok0t15y9atgyjz.m.pipedream.net
  • HTTP Method: Choose from GET, POST, PUT, PATCH, or DELETE. Most webhook consumers expect POST.
  • Headers (Optional): You can include any number of custom headers using key-value pairs. These might be needed for authentication or content type. Example:
  • Signing key (Optional): Lets your endpoint verify that a request really came from us. Generate a key in the step editor, or pick a secret from your secret store. See verifying signed webhooks below.
  • Body (Optional): This is the payload that will be sent in the request body. It supports workflow variable interpolation, so you can include values like the incident name or ID dynamically.
    • Using the dashboard editor
    To add variables to your webhook body in the dashboard:
    1. Position your cursor where you want the variable inserted
    2. Click the “Insert variable” button in the body field’s toolbar
    3. Select the variable you need (e.g., incident → id) The variable will appear as a highlighted badge in the editor, and will be replaced with the actual value when the webhook is sent.
    • Using the API
    If you’re creating workflows via the API, you can use {{variable.path}} syntax in your request body and it will be parsed into interpolatable variables. For example:

​
Example Use Cases

Here are a few examples of how you might use the “Send a webhook” step:
  • Notifying an Internal Tool: Send a webhook to a custom in-house dashboard to update a real-time incident feed with the latest incident status or metadata.
  • Triggering a Runbook in an External System: Use the webhook to start an automated runbook in systems like RunDeck when an incident enters a particular state (e.g. Critical or Resolved ).
  • Syncing with a Ticketing System: Push incident data into a ticketing system to create or update a linked issue whenever an incident is created.
  • Logging to an Audit Service: Send a record of key incident lifecycle events (e.g. status changed to Resolved, or lead updated) to a logging service or data warehouse.
  • Broadcasting to a Notification Bot: Trigger a message via a custom Slack bot or Discord bot that posts structured incident details in a dedicated alerting channel.

​
Verify that a webhook came from us

Every webhook sent by a workflow includes a webhook-id header (unique to that delivery) and a webhook-timestamp header (Unix seconds). If you configure a signing key on the step, we also sign every request. Your endpoint can then check the signature and reject anything that didn’t come from us. When signing is on, each request includes a webhook-signature header. If that header name doesn’t suit your receiver, you can pick a different one on the step. The signature uses the same scheme as the webhooks you configure in Settings, so you can verify it with the Svix libraries or manually. Two notes on keys:
  • A key generated in the step editor starts with whsec_ and works as-is in a Svix verifier.
  • A secret from your secret store is used exactly as stored. To verify with the Svix libraries, base64-encode it and add the whsec_ prefix.

​
Things to Note

  • The request will timeout after 15 seconds if your endpoint doesn’t respond in time.
  • Each webhook includes an Idempotency-Key header with a value that’s unique to that step run. If we retry a delivery, the retry carries the same key, so your endpoint can use it to detect duplicates and process each event only once.
  • Make sure your endpoint can handle incoming requests reliably. Use tools like Pipedream or RequestBin for testing.