---
title: "Delete a recipient group"
method: DELETE
path: "/api/v1/recipient-groups/{group}"
tags: ["Recipient groups"]
---

# Delete a recipient group

`DELETE /api/v1/recipient-groups/{group}`

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

Soft-deletes the group — but only while your alert routing does not point at it. A group an alert source, a routing rule or an alert template still targets answers 409 with the list of what targets it, and stays. The foreign keys there are ON DELETE SET NULL, so deleting would not break inbound alerts from Grafana or Zabbix — it would leave them with NO recipient: the alert still arrives, still lands in triage, and wakes nobody. A template default is the same story from the other side: firing a template whose `default_group_uuid` no longer resolves answers 422 and the alert reaches nobody. Members are untouched either way; notification history keeps pointing at the row. Repeating the call on an already-deleted group returns 404.

## Path parameters

- `group` string, uuid, required

## Response `204`

Deleted.

## Other responses

- `401`: API key missing, invalid, revoked or expired.
- `403`: API key lacks config.write, or the group belongs to another company.
- `404`: No group 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)