---
title: "Retry a failed notification"
method: POST
path: "/api/v1/notifications/{notification}/retry"
tags: ["Notifications"]
---

# Retry a failed notification

`POST /api/v1/notifications/{notification}/retry`

## 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}/retry`
- Auth: API key in header `X-API-Key`

## Path parameters

- `notification` string, uuid, required

## Response `200`

Notification retried — or, when `owner_fallback` is present, the retry reached nobody either and the account owner was emailed again. See `OwnerFallbackNotice`.

- object
  - `owner_fallback` OwnerFallbackNotice: Present on a send response only when the alert reached NOBODY it was addressed to and the umbrella guarantee fired instead: the company owner was emailed that delivery failed. **This is the one case where `success: true` does not mean somebody was paged.** The response reads as a success because the alert was rescued rather than lost, and because retrying it would only mail the owner a second time — but the person it was addressed to received nothing. Never report the alert as delivered when this object is present; report that delivery failed and the owner was told. `reason` says what to repair, and it is the same vocabulary the rest of the API uses for delivery verdicts: `no_deliverable_route` (no channel could carry it — `GET /recipients/{recipient}` and `GET /capabilities` say which of the recipient, their contacts or the installation is the blocker), `delivery_failed` (routes existed and every attempt failed at send time), `escalation_exhausted` (the chain ran through every step and reached nobody), `group_unreachable` (a group fan-out reached none of its members). What the email itself contains is an operator setting, not an API one: either the alert text, or — with the redacted mode switched on — only the fact, the reason and a link to the alert in the dashboard. Either way it is a real outbound email: it counts toward the daily anti-abuse ceiling, and it is reported separately from alerts in the usage report, because it is the consequence of a failed delivery rather than traffic the account asked for.
    - `engaged` boolean: Always true when the object is present.
    - `delivered` boolean: Whether the email to the owner itself went out. False means the alert was lost outright — the loudest failure this API can report.
    - `reason` 'no_deliverable_route' | 'delivery_failed' | 'escalation_exhausted' | 'group_unreachable': Why the intended delivery did not happen.
    - `intended_recipient_uuid` string, uuid: The recipient that got nothing. This is the one to repair.
    - `alert_notification_id` string, uuid: UUID of the original alert — the one that failed. Poll THIS through `GET /notifications/{notification}/status`; it stays `failed`. The top-level `notification_id` of the response names the owner email instead, and that one is `completed`.

## Other responses

- `401`: API key missing, invalid, revoked or expired.
- `403`: API key lacks the notifications.send ability.
- `422`: Cannot retry

---

[API](https://skmtc.dev/wardenpoint/apis/wardenpoint-api.md) · [All operations](https://skmtc.dev/wardenpoint/apis/wardenpoint-api/llms.txt) · [OpenAPI document](https://skmtc.dev/wardenpoint/apis/wardenpoint-api/revisions/259ee445728e?raw)