Queue another delivery attempt of a notification

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.