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

POST /api/v1/automation/webhooks/{webhookKey}
SettingValue
MethodPOST
Content-Typeapplication/json
AuthenticationBearer token (Authorization: Bearer <secret>)
Rate Limit60 requests per minute per webhook key
Idempotency5-minute deduplication window

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):
{
  "variables": {
    "key1": "value1",
    "key2": "value2",
    "nested": {
      "key": "value"
    }
  }
}
FieldTypeRequiredDescription
variablesobjectNoCustom key-value pairs accessible in the workflow as {{webhook.key}}
The request body is optional. Sending an empty body or {} triggers the workflow without custom variables.

Response Format

Success (200 OK)

{
  "success": true,
  "data": {
    "executionId": "exec-abc123-def456",
    "status": "running",
    "startedAt": "2024-01-15T10:30:00.123Z"
  }
}

Duplicate Request (200 OK, cached)

If the same payload is sent within the 5-minute idempotency window:
{
  "success": true,
  "data": {
    "executionId": "exec-abc123-def456",
    "status": "running",
    "startedAt": "2024-01-15T10:30:00.123Z",
    "deduplicated": true
  }
}

Error Responses

StatusCodeDescription
401unauthorizedMissing or invalid Bearer token
404webhook_not_foundWebhook key does not exist or workflow is inactive
429rate_limit_exceededToo many requests (60/min limit)
500internal_errorServer error during execution
Error format (RFC 7807):
{
  "type": "about:blank",
  "title": "Unauthorized",
  "status": 401,
  "code": "unauthorized",
  "detail": "Invalid or missing webhook secret",
  "timestamp": "2024-01-15T10:30:00.000Z",
  "instance": "/api/v1/automation/webhooks/wh_abc123"
}

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:
MechanismHow It Works
AutomaticPayload hash is used as the idempotency key. Identical payloads within 5 minutes return the cached execution.
ExplicitSend X-Idempotency-Key: your-unique-key header. Requests with the same key within 5 minutes return the cached execution.
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

curl -X POST \
  https://api.easyalert.io/api/v1/automation/webhooks/wh_abc123 \
  -H "Authorization: Bearer your_webhook_secret_here" \
  -H "Content-Type: application/json" \
  -d '{
    "variables": {
      "deployment": "v2.1.0",
      "environment": "production",
      "commit": "abc123def",
      "triggeredBy": "github-actions"
    }
  }'

Using Variables in Workflows

Variables sent in the webhook payload are available in the workflow as {{webhook.<key>}}:
// Webhook payload
{
  "variables": {
    "deployment": "v2.1.0",
    "environment": "production",
    "services": ["payment-api", "auth-service"]
  }
}
Usage in workflow nodes:
NodeTemplateResolves To
Slack messageDeploying {{webhook.deployment}} to {{webhook.environment}}Deploying v2.1.0 to production
Condition{{webhook.environment}} equals productionRoutes to production-specific flow
ForEachCollection: {{webhook.services}}Iterates over ["payment-api", "auth-service"]
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