Detaches the recipient from every monitor it was attached to (cascade) and deletes it. Deletes the recipient's own pending/retrying webhook_deliveries rows so nothing keeps retrying to a removed destination.

Guarded delete (issue #396). An optional ?replaced_by= runs a stricter path instead: the recipient is deleted only if a replacement recipient already covers every one of its live (pending/retrying) deliveries. Omitting replaced_by keeps the plain, unguarded behavior described above exactly.

Four checks, all evaluated in one transaction, each failing with 409 and its own named reason:

• replacement_not_ready: the replacement must exist in the same account, differ from the recipient being deleted, be active (not disabled; not an unconfirmed email recipient), have events that are a superset of the recipient being deleted's, and — when the recipient being deleted is an account default — itself be a default too.
• recipient_not_active: the recipient being deleted must itself be active. An inactive recipient already lost its live deliveries when it went inactive, so a guarded delete would prove nothing; use the plain DELETE instead.
• attachment_missing: every monitor the recipient being deleted is attached to must have the replacement attached too, with the same down_delay_s.
• delivery_not_covered: every live delivery of the recipient being deleted must have a non-null enqueued_at strictly after the replacement's attached_at on that monitor (see GET /api/v1/monitors/{id}/recipients), AND a same-transition sibling delivery for the replacement (same monitor, event type, and occurrence) whose status is pending, retrying, or delivered.

What a 204 guarantees, and what it doesn't. The checks hold at the instant the delete commits — every removed delivery had a replacement copy that was delivered or still live at that instant. It does NOT mean the deleted recipient's destination goes quiet immediately: an attempt the delivery worker already claimed before the commit can still reach it once more, signed with its credentials, with no delivery-log row recording it — we recommend keeping the old destination (and, for a secret rotation, the old signing secret) accepting requests for at least five minutes after the 204. After the commit, the replacement is an ordinary recipient — a later edit to it (unsubscribe, delete, narrowed events, changed Slack/PagerDuty configuration) affects its own deliveries the same as for any recipient.

Drain recipe. Before calling this with replaced_by: create and attach the replacement everywhere the original recipient is attached (same events, same down_delay_s, same default status), then scan GET /api/v1/webhook-deliveries?recipient_id={id}&status=pending&status=retrying&order=id until next_cursor is null and every returned row's enqueued_at is non-null and greater than the replacement's attached_at on its monitor. Until the guarded delete returns 204, avoid detaching, unsubscribing, deleting (without replaced_by), or otherwise editing the original recipient in any way that removes or cancels its live deliveries — the guard can only see rows that still exist, and any of those actions empties the scan and lets a later guarded delete succeed with the alert already silently lost.