---
title: "Queue another delivery attempt of a notification"
method: POST
path: "/api/v1/notifications/{notification}/retry-async"
tags: ["Notifications"]
---

# Queue another delivery attempt of a notification

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

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

Queues a fresh delivery attempt of a notification that already exists, reusing its stored message, recipient and priority. Routes are rebuilt at retry time, so a contact repaired since the failure is used — this is the endpoint to call after fixing what made the delivery fail.

**"Async" means the answer says nothing about the outcome.** The 202 is acknowledgement that a job was queued, not that anything was delivered or even attempted; the worker picks it up afterwards. The result becomes visible only through `GET /api/v1/notifications/{notification}/status`, where the status moves from `pending` through `processing` to one of the four terminal values — `completed`, `failed`, `cancelled` or `acknowledged`. Stop polling on any of those four, not on `completed`/`failed` alone: a notification a human confirms ends in `acknowledged`. Nothing in this response distinguishes a retry that will succeed from one that will fail again.

**Not idempotent.** Every call queues another attempt, and each attempt that gets through reaches the person again. A client retrying on timeout delivers twice. Check the notification's status before calling rather than calling repeatedly.

**A notification already in `completed` is not retried — and still answers 202.** The refusal happens inside the worker path and is only recorded in the server log; the response is indistinguishable from a real retry. Read the status first if you need to know whether anything was queued.

Use the synchronous sibling `POST /api/v1/notifications/{notification}/retry` when you want the delivery result in the response instead; it costs a blocking call but tells you what happened.

## Path parameters

- `notification` string, uuid, required

## Request body

- object
  - `queue` string, nullable: Name of the queue to dispatch onto. Defaults to `default`, which is what the workers consume. Naming a queue nothing consumes accepts the request and silently never delivers — leave it out unless the operator told you a queue name.

## Response `202`

A retry job was queued — or the notification was already complete and nothing was queued, which looks the same from here.

- object
  - `success` boolean
  - `queued` boolean
  - `message` string
  - `notification_id` string, uuid: The notification's UUID, despite the field name. Same value you passed in the path.
  - `queue` string: Queue the job went onto — `default` unless you named one.

## Other responses

- `401`: API key missing, invalid, revoked or expired.
- `402`: The company subscription is inactive. Retries are blocked with everything else that sends.
- `403`: API key lacks the notifications.send ability. A retry is a send, so a read-only key cannot do it.
- `404`: No notification with this UUID.
- `429`: The plan's notification quota is spent — a retry consumes quota exactly as a new send does. The body carries `code: LIMIT_EXCEEDED`, the current usage and an `upgrade_url`.

---

[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)