---
title: "Delete a recipient"
method: DELETE
path: "/api/v1/recipients/{recipient}"
tags: ["Recipients"]
---

# Delete a recipient

`DELETE /api/v1/recipients/{recipient}`

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

Soft-deletes the recipient — but only while nothing holds them. Someone who belongs to a group, has a current or upcoming shift or handover, is named in an escalation step, or is a template default answers 409 with the list of what holds them, and stays. That refusal matters most for duty: the delete is soft, so their shifts survive in the database while the link goes under the soft-delete scope, and the schedule starts answering «nobody is on call» — data intact, duty gone. Past shifts do not hold: history is not a reference. Notification history keeps pointing at the row either way. Repeating the call on an already-deleted recipient returns 404.

## Path parameters

- `recipient` string, uuid, required

## Response `204`

Deleted.

## Other responses

- `401`: API key missing, invalid, revoked or expired.
- `403`: API key lacks config.write, or the recipient belongs to another company.
- `404`: No recipient with this UUID.
- `409`: Something still points at it, so it was NOT deleted. The body carries `code: ENTITY_IN_USE` and a `references` list — each entry names what holds it (`type`, `uuid`, `name`, and sometimes a `detail` like «2 shifts»). Detach it there and repeat; there is no force flag.

---

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