Replace the set of recipients attached to a monitor

Full replacement, not a merge. recipient_ids entries must be positive and unique (400 before any write, for either violation). An id not owned by the calling account returns 400 and writes nothing. Removing a recipient from the set cancels that pair's queued (pending/retrying) webhook_deliveries rows in the same transaction, not just future transitions — but this is a bound on enqueued state, not a guarantee about what has already left the wire: the same documented race as delivery supersede (see docs/SPEC.md's outbox section) means an attempt the Worker already passed its liveness check for just before this transaction commits can still complete. Whether it is recorded in the delivery log depends on which update commits first: if this transaction's delete (scoped to pending/retrying rows) runs first, the row is gone and the Worker's later terminal-status update is a no-op, so the attempt is NOT recorded; if the Worker's terminal-status update lands first, the row is already delivered (or failed) and this transaction's delete — which only targets pending/retrying rows — leaves it in place, so the attempt IS recorded. Both outcomes are possible; this is not a guarantee either way. {"recipient_ids": []} detaches everything, after which silent_monitors on GET /api/v1/account counts this monitor if it is still enabled.

put/api/v1/monitors/{monitorID}/recipients

Request

  • Base URL: https://api.uptimemonitoring.com
  • URL: https://api.uptimemonitoring.com/api/v1/monitors/{monitorID}/recipients
  • Auth: HTTP bearer

Path parameters

monitorIDinteger required

Monitor ID.

Request body

recipient_idsinteger[]

Must be positive and unique.

Response

The resulting attached set

recipient_idsinteger[]

Must be positive and unique.

Changes

No recorded changes to this operation across all 1 revision of this API.