Notifications

Get notification status with channels and attempts

The only way to learn what happened to anything sent asynchronously — the 202 from a send says nothing about delivery.

Poll until status is one of the FOUR terminal values (completed, failed, cancelled, acknowledged), then stop. Polling only for completed/failed is the mistake this endpoint invites: an alert a human confirms ends in acknowledged and never moves again, so that loop runs until it times out and then reports "still delivering" about an incident that was closed.

channels lists one entry per channel tried, in the order they were tried, each with its own status and attempt counters — that is where a partial failure is visible. error_message carries the last failure; it can be set on a notification that later succeeded through a fallback channel, so read it together with the top-level status rather than on its own.

A failed alert may still have been rescued, and this is where an async send reveals it. WardenPoint never loses an alert silently: when every channel for the recipient fails, the company owner is emailed that delivery did not happen. The alert itself stays failed — nobody was paged — and carries delivered_via_owner_fallback: true in metadata; the rescue email is a separate notification of its own, marked is_owner_fallback: true. Do not read the rescue as a delivery, and do not retry on the strength of it: a retry pages the owner again and still not the person.

get/api/v1/notifications/{notification}/status

Request

  • Base URL: https://wardenpoint.com (the document declares no server; this is the origin it was published from)
  • URL: https://wardenpoint.com/api/v1/notifications/{notification}/status
  • Auth: API key in header X-API-Key

Path parameters

notificationstring uuid required

Notification UUID, as returned by the send endpoints.

Response

Current state of the notification.

uuidstring uuid
status'pending' | 'processing' | 'completed' | 'failed' | 'cancelled' | 'acknowledged' | 'escalating'

Lifecycle state of a notification. FOUR of the seven are terminal and will never change again: completed, failed, cancelled, acknowledged. Poll until you see one of those four — waiting only for completed or failed hangs until your own timeout on every alert a human confirms.

pending — created, waiting for a worker. Not terminal. processing — a worker is delivering it right now. Not terminal. escalating — delivery happened, nobody confirmed in time, and the escalation chain is walking to the next person. Not terminal: it still ends in acknowledged or failed. completed — delivered. TERMINAL. failed — every channel and attempt was exhausted without delivery. TERMINAL, and the only status retry accepts. cancelled — stopped before delivery, by the cancel endpoint. TERMINAL. acknowledged — a human confirmed it and the escalation chain stopped. TERMINAL, and the outcome the product exists for: an alert that reaches this has done its job.

priority'low' | 'normal' | 'high' | 'critical'
messagestring

The text as it was sent.

audio_filestring nullable
is_owner_fallbackboolean

True when this notification IS the rescue email to the account owner rather than an alert of yours. The alert it was sent about is named by original_notification_uuid in metadata, and owner_fallback_reason there says why delivery failed.

total_attemptsinteger

Delivery attempts across all channels.

external_idstring nullable

Provider-side identifier of the delivered message or call, when the provider gives one.

error_messagestring nullable

Last delivery error. Present on failed, and possibly on a notification that later succeeded through a fallback.

metadataobject nullable
created_atstring date-time
completed_atstring date-time nullable

Set once the notification reaches a terminal status; null while it is still moving.

acknowledged_atstring date-time nullable

When a human took the alert. Null on anything that was never acknowledged. This is the moment the escalation chain stopped, so acknowledged_at - created_at is the response time of this incident.

acknowledged_viastring nullable

The label recorded with the acknowledgement — the source you sent to the acknowledge endpoint (default api), or the surface the platform acknowledged from on its own: telegram_callback, dtmf, dashboard, email_link, and so on. Null on anything that was never acknowledged. Together with acknowledged_at this is the audit trail the acknowledge endpoint promises; nothing else exposes it.

Changes

No recorded changes to this operation across all 1 revision of this API.