Notifications
EventDestinations, webhook signing, and delivery log
When an Alert produces an AlertEvent, Stream Estate delivers it through an EventDestination. Every delivery attempt is recorded as an EventNotification.
EventDestination
Root endpoint: /account/event-destinations
| Field | Type | Description |
|---|---|---|
id | string (uuid) | |
url | string | null | Webhook URL, HTTPS required |
isDefault | boolean | Your account default destination. Pass true to promote this one; the previous default is demoted. Your first destination becomes the default automatically. |
status | enum | ACTIVE or SUSPENDED (circuit breaker) |
signingKey | string | null | HMAC key, see below |
createdAt / updatedAt | string | null | ISO 8601 |
A destination can also be created on the fly from POST /alerts — see Alert.
Endpoints
GET /account/event-destinations— listPOST /account/event-destinations— createGET /account/event-destinations/{uuid}— detailDELETE /account/event-destinations/{uuid}— delete
A SUSPENDED destination reactivates on its own as soon as your endpoint answers again — see Circuit breaker. The console lets you force reactivation without waiting for the next probe: console.stream.estate/webhooks.
Signing key (signingKey)
The HMAC key belongs to the account, not to a destination: a single key signs all your webhooks.
It is returned once only, in the response of the call that creates the very first webhook destination of your account — whether that call is a POST /account/event-destinations or a POST /alerts carrying webhookUrl. Destinations created later reuse the same key and no longer return it. Store it on receipt: it can never be read again.
Lost or compromised: rotate it from the console, console.stream.estate/webhooks — the new key is shown once and the old one is invalidated immediately.
Every POST to your endpoint is signed with this key. Verify the HMAC-SHA256 header on receipt before processing the payload (exact header names: see Webhooks).
EventNotification (delivery log)
Root endpoint: /event-notifications
| Field | Type | Description |
|---|---|---|
id | string (uuid) | |
destinationAddress | string | Target URL |
status | enum | PENDING, DELIVERED, FAILED, SUSPENDED |
attemptNumber | integer | Number of attempts |
deliveredAt | string | null | Successful-delivery timestamp |
lastErrorMessage | string | null | Last error message |
createdAt / updatedAt | string | null | ISO 8601 |
Endpoints
GET /event-notifications— list, paginated via?page=N(any filtering by status happens client-side in your code)GET /event-notifications/{uuid}— detail
Circuit breaker
After too many consecutive failures, the destination flips to SUSPENDED and subsequent notifications are recorded as SUSPENDED in the log, with no delivery attempt.
Recovery is automatic. Every 5 minutes, Stream Estate probes the destination by replaying one pending notification. As soon as your endpoint answers 2xx, the destination flips back to ACTIVE and the suspended notifications are replayed progressively, oldest first. While the endpoint keeps failing, the interval between probes doubles, up to a 6-hour ceiling — do not expect an instant resume after a long outage.
In practice, once your receiver is fixed: either wait for the next probe, or force reactivation from the console, console.stream.estate/webhooks, and the replay starts immediately.
At most 5,000 notifications are kept per suspended destination. Beyond that, events keep being produced (visible through GET /alerts/{alertId}/events) but no notification is created for them: they will not be replayed. Fix or replace a failing endpoint before reaching that cap.