Static Documentation

Event Orchestration API

Version latest · Updated 2026-08-12
Interactive docs View on GitHub

Event Orchestration API#

Event Orchestration is the versioned event-processing layer between integration normalizers and the existing alert lifecycle.

The generated OpenAPI document is available at /api/openapi.json, and Swagger UI is available at /docs.

For a UI-first explanation, safe rollout procedure and practical examples, read the Event Orchestration user guide.

Authentication and permissions#

All control-plane endpoints require a JWT or personal API token:

Authorization: Bearer <token>

Effective access is scoped to the orchestration group:

Group roleAccess
viewerRead orchestrations, versions and executions
editorRead, create, edit, validate, simulate, replay, publish and rollback
user_adminRead orchestrations and executions
Global administratorAll permissions, including delete and webhook-action management

Every orchestration response includes a permissions object so clients can hide actions the current principal cannot execute.

Lifecycle#

A new orchestration starts disabled and has one editable draft.

Create -> edit draft -> validate -> simulate -> publish
                                      |
                                      +-> immutable version

Published versions are immutable. A rollback copies a historical definition into a new version and publishes that new version; it never edits the historical row.

Main endpoints:

GET    /api/event-orchestrations
POST   /api/event-orchestrations
GET    /api/event-orchestrations/{orchestration_id}
PATCH  /api/event-orchestrations/{orchestration_id}
DELETE /api/event-orchestrations/{orchestration_id}

POST   /api/event-orchestrations/{orchestration_id}/draft
PUT    /api/event-orchestrations/{orchestration_id}/draft
POST   /api/event-orchestrations/{orchestration_id}/validate
POST   /api/event-orchestrations/{orchestration_id}/publish
POST   /api/event-orchestrations/{orchestration_id}/rollback
PATCH  /api/event-orchestrations/{orchestration_id}/runtime

GET    /api/event-orchestrations/{orchestration_id}/versions
GET    /api/event-orchestrations/{orchestration_id}/versions/{version_id}
POST   /api/event-orchestrations/{orchestration_id}/simulate
POST   /api/event-orchestrations/{orchestration_id}/replay
GET    /api/event-orchestrations/{orchestration_id}/executions
GET    /api/event-orchestrations/{orchestration_id}/shadow-metrics

The editor catalog endpoint returns group-scoped services, teams, routes, policies, normalizer sources, webhook actions and effective permissions:

GET /api/event-orchestrations/catalog?group_id=1

Create an orchestration#

A service-scoped orchestration requires service_id. A global orchestration must not specify one.

{
  "group_id": 1,
  "name": "Production routing",
  "description": "Normalize production alerts before lifecycle processing",
  "scope": "global",
  "compatibility_mode": "hybrid"
}

Conditions#

A condition tree is either one leaf condition or one logical group:

{
  "all": [
    {
      "field": "labels.environment",
      "operator": "equals",
      "value": "production"
    },
    {
      "any": [
        {
          "field": "event.severity",
          "operator": "equals",
          "value": "critical"
        },
        {
          "field": "labels.priority",
          "operator": "in",
          "value": ["p1", "p2"]
        }
      ]
    }
  ]
}

Logical keys are:

  • all — AND;
  • any — OR;
  • none — NOT: none of its children may match.

The OpenAPI OrchestrationCondition schema contains the exact operator enum supported by the running release.

Actions#

Rules execute deterministic built-in actions. They can mutate event fields and labels, extract variables, select routing and policies, change grouping, suppress/drop/pause processing, add notes or enqueue a configured webhook.

Example draft:

{
  "rules": [
    {
      "name": "Route critical production alerts",
      "enabled": true,
      "condition_tree": {
        "all": [
          {
            "field": "labels.environment",
            "operator": "equals",
            "value": "production"
          },
          {
            "field": "event.severity",
            "operator": "equals",
            "value": "critical"
          }
        ]
      },
      "actions": [
        {"type": "set_team", "team_id": 4},
        {"type": "set_priority", "value": "P1"},
        {"type": "set_label", "name": "orchestrated", "value": "true"}
      ],
      "processing_mode": "continue",
      "children": []
    }
  ],
  "comment": "Route critical production alerts"
}

Arbitrary shell, Python, SSH and container execution are not supported.

Validate, simulate and publish#

Validation checks the current draft:

POST /api/event-orchestrations/{orchestration_id}/validate

Simulation accepts either one normalized event or one raw integration payload. It does not create alerts, change production state or execute webhooks.

{
  "normalized_event": {
    "source": "webhook",
    "title": "Database unavailable",
    "severity": "critical",
    "labels": {"environment": "production"}
  },
  "compare_with_active": true
}

Publishing creates an immutable version:

{
  "comment": "Reviewed and ready for production",
  "confirm_catch_all_drop": false
}

Catch-all drop rules require explicit confirmation.

Author metadata#

Version responses distinguish the people involved:

  • created_by — created the version row;
  • updated_by — last changed the draft definition;
  • published_by — published the immutable version.

Each field has a matching *_id value. User objects contain id, username, optional display_name and a display-ready label.

Runtime modes#

{
  "mode": "shadow",
  "compatibility_mode": "hybrid"
}

Runtime modes:

  • disabled — orchestration does not run;
  • shadow — decisions are recorded but cannot change production behavior;
  • active — published decisions are applied.

A published version is required before shadow or active can be enabled.

Webhook actions#

Reusable webhook actions use a separate API:

GET    /api/orchestration-webhook-actions?group_id=1
POST   /api/orchestration-webhook-actions
PATCH  /api/orchestration-webhook-actions/{action_id}
DELETE /api/orchestration-webhook-actions/{action_id}
GET    /api/orchestration-webhook-actions/{action_id}/executions

Secret headers are write-only. IncidentRelay encrypts them and never returns them in API responses. Execution records expose only redacted response excerpts and safe error text.