Skip to main content

Overview

The Webhook API allows external systems to trigger EasyAlert workflows via HTTP POST requests. Use it to integrate with CI/CD pipelines, monitoring tools, custom scripts, or any system that can make HTTP calls. Common use cases:
  • Trigger a deployment rollback workflow from your CI/CD pipeline
  • Start an incident response workflow from a custom monitoring tool
  • Execute a maintenance workflow from a cron job or scheduler
  • Chain automation workflows across different platforms

Endpoint


Authentication

Webhook requests require a Bearer token for authentication. The token (secret) is generated alongside the webhook key.
1

Enable Webhook Trigger

In the workflow designer, set the trigger type to Webhook in the Trigger node inspector.
2

Generate Webhook Key

Click Generate Webhook Key. This creates:
  • Webhook Key — Part of the URL (visible, not sensitive)
  • Webhook Secret — Bearer token for authentication (sensitive)
3

Copy the Secret

Copy the webhook secret immediately. It is displayed only once and cannot be retrieved later.
4

Include in Requests

Add the secret as a Bearer token in the Authorization header of your HTTP requests.
The webhook secret is shown only once when generated. If you lose it, you must regenerate the webhook key — which also changes the URL.

Request Format

Body (optional):
The request body is optional. Sending an empty body or {} triggers the workflow without custom variables.

Response Format

Success (200 OK)

Duplicate Request (200 OK, cached)

If the same payload is sent within the 5-minute idempotency window:

Error Responses

Error format (RFC 7807):

Rate Limiting & Idempotency

Rate Limit

Each webhook key is limited to 60 requests per minute. Exceeding the limit returns HTTP 429 with a Retry-After header.

Idempotency

Duplicate detection prevents the same event from triggering multiple executions:
Use the X-Idempotency-Key header when your source system retries on failures. This prevents duplicate workflow runs even if the payload changes slightly between retries.

Code Examples


Using Variables in Workflows

Variables sent in the webhook payload are available in the workflow as {{webhook.<key>}}:
Usage in workflow nodes:
Nested variables are supported: {{webhook.config.timeout}} accesses {"variables": {"config": {"timeout": 30}}}.

Troubleshooting

Cause: Missing or invalid Bearer token.Steps:
  1. Verify the Authorization: Bearer <secret> header is present
  2. Confirm the secret matches what was generated (it’s shown only once)
  3. Check for extra whitespace or line breaks in the secret
  4. If unsure, regenerate the webhook key and use the new secret
Cause: The webhook key doesn’t exist, or the workflow is not active.Steps:
  1. Verify the webhook key in the URL matches the one shown in the workflow settings
  2. Confirm the workflow is published and activated
  3. Check if the webhook key was regenerated (which changes the URL)
Cause: More than 60 requests sent in one minute.Steps:
  1. Check the Retry-After header for when to retry
  2. Add backoff logic to your client
  3. Batch events or reduce call frequency
  4. Use X-Idempotency-Key to deduplicate retries safely
Cause: Variables not included in the variables field of the payload.Steps:
  1. Verify your payload includes the "variables": {...} wrapper
  2. Check that variable names match what the workflow expects (case-sensitive)
  3. Verify the Content-Type header is application/json
  4. Test with cURL to isolate whether the issue is client-side
Cause: Retries from your source system without idempotency.Steps:
  1. Add X-Idempotency-Key header with a unique key per logical event
  2. If using automatic dedup, note that different payloads create different executions even for the same logical event
  3. The dedup window is 5 minutes — events older than 5 minutes are treated as new