Events
| Event | Fires when |
|---|---|
alert.created | A new Tier A match opens an alert |
case.created | A case is opened from a triaged alert |
case.reminder | A deadline reminder fires for an open case |
case.overdue | A case's current stage is read as overdue |
case.stage_submitted | Any stage (early warning, notification, final) is marked submitted |
case.closed | A case reaches its terminal closed state |
Payload shape
Every delivery is a JSON body with the same top-level shape:
{
"event": "alert.created",
"sentAt": "2026-09-13T12:00:00.000Z",
"title": "...",
"detail": "...",
"url": "https://your-declara-host/alerts/...",
"data": { }
}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:
- Recompute the HMAC over the exact timestamp and raw request body using your signing key.
- Compare it to
X-Declara-Signaturein constant time. - 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 is best-effort: a failing or unreachable endpoint doesn't block the event that triggered it, and every attempt is recorded so a channel that's stopped working is visible rather than silently assumed healthy. This page does not document a retry count or backoff schedule — confirm current behavior with your integration contact before depending on a specific retry guarantee.