Skip to content
Declara
⌘K
engineer

Webhook event catalog

Was this page helpful?

Events

EventFires when
alert.createdA new Tier A match opens an alert
case.createdA case is opened from a triaged alert
case.reminderA deadline reminder fires for an open case
case.overdueA case's current stage is read as overdue
case.stage_submittedAny stage (early warning, notification, final) is marked submitted
case.closedA case reaches its terminal closed state
crypto.disallowedA new SBOM declares cryptography that NIST or BSI guidance disallows and the version (or, for a version's first SBOM, the product's latest other version) did not already declare. data.algorithms lists them. Not an exploited vulnerability, and no clock starts

Payload shape

Every delivery is a JSON body with the same top-level shape:

{
  "id": "clx…",
  "event": "alert.created",
  "sentAt": "2026-09-13T12:00:00.000Z",
  "title": "...",
  "detail": "...",
  "url": "https://your-declara-host/alerts/...",
  "data": { }
}

id identifies the delivery and stays the same when it is retried. title and detail are meant for a human reading a chat notification. data carries the structured fields a program should read instead of parsing the prose.

Verifying a delivery

Every delivery is HMAC-signed, with two headers:

  • X-Declara-Timestamp — the Unix timestamp the signature was computed against.
  • X-Declara-Signature — an HMAC-SHA256 of ${timestamp}.${body}, using your endpoint's signing key.

Verify it yourself before trusting a payload:

  1. Recompute the HMAC over the exact timestamp and raw request body using your signing key.
  2. Compare it to X-Declara-Signature in constant time.
  3. Reject deliveries where the timestamp is too far from the current time, to guard against a replayed request.

Verifying the signature is the integrator's responsibility — Declara signs every delivery, but nothing on the receiving end checks it for you.

Delivery behavior

Delivery never blocks the event that triggered it, and every attempt is recorded, so a channel that has stopped working shows up in settings instead of being assumed healthy.

A delivery that fails because your endpoint was unreachable, timed out, or answered 408, 429 or 5xx is tried again up to four more times: after roughly 30 minutes, 1 hour, 3 hours and 6 hours, checked hourly. Each retry is signed afresh with a new X-Declara-Timestamp, so the replay window still applies. Any other 4xx or a redirect is treated as a refusal and not retried. Deliveries to an endpoint that has been switched off are not resent when it is switched back on.

Because a retry can arrive after a slow success you did not acknowledge in time, treat deliveries as at-least-once and deduplicate on id.

An Article 14 drill delivers nothing: no case.* event, reminder or overdue notice is sent for a practice case.

Related