`GET`/`PUT` responses always carry both `recipient_ids` and `recipients` (resolved from the same snapshot), so a client reading either field sees the attached set. `PUT` request bodies accept exactly one of `recipient_ids` (today's form) or `recipients` (issue #338, per-pair `down_delay_s`) — specifying both, or specifying neither, is 400. Either field, when present, must not be JSON `null` (400) — only an explicit `[]` detaches every recipient. Omitting `down_delay_s` on a `recipients` entry keeps an already-attached pair's stored delay, or defaults a newly-attached pair to `0`; the `recipient_ids` form always keeps every attached pair's existing delay.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://artifacts.apis.io/uptimemonitoring-com/json-schema/uptimemonitoring-com-monitor-recipients-schema.json",
"title": "MonitorRecipients",
"description": "`GET`/`PUT` responses always carry both `recipient_ids` and\n`recipients` (resolved from the same snapshot), so a client reading\neither field sees the attached set. `PUT` request bodies accept\nexactly one of `recipient_ids` (today's form) or `recipients`\n(issue #338, per-pair `down_delay_s`) — specifying both, or\nspecifying neither, is 400. Either field, when present, must not\nbe JSON `null` (400) — only an explicit `[]` detaches every\nrecipient. Omitting `down_delay_s` on a `recipients` entry keeps an\nalready-attached pair's stored delay, or defaults a newly-attached\npair to `0`; the `recipient_ids` form always keeps every attached\npair's existing delay.\n",
"x-generated": "2026-10-31",
"x-method": "derived",
"x-generator": "derive-json-schema.py",
"x-source": "openapi/uptimemonitoring-com-openapi.yaml#/components/schemas/MonitorRecipients",
"type": "object",
"properties": {
"recipient_ids": {
"type": "array",
"items": {
"type": "integer",
"format": "int64"
},
"description": "Must be positive and unique."
},
"recipients": {
"type": "array",
"items": {
"type": "object",
"required": [
"id"
],
"additionalProperties": false,
"properties": {
"id": {
"type": "integer",
"format": "int64"
},
"down_delay_s": {
"type": "integer",
"enum": [
0,
60,
120,
180,
240,
300,
600,
900,
1200,
1500,
1800,
3600,
7200,
10800,
14400
],
"description": "Seconds to hold a \"down\" alert before sending it, so a\nblip shorter than this never reaches the recipient at\nall — like Monitive's alert delay. `up`/`flapping` are\nalways immediate. Optional on write; always present on\nread.\n"
},
"attached_at": {
"type": "string",
"format": "date-time",
"description": "Read-only (issue #396) — when this monitor/recipient\nattachment was made, stamped by the Postgres server\nclock. A kept attachment keeps its `attached_at` across\na `PUT` that only changes its `down_delay_s`. This is\nthe per-monitor boundary\n`DELETE /api/v1/recipients/{recipientID}?replaced_by=`\nmeasures a replacement recipient's delivery coverage\nagainst. Ignored if sent on a request.\n"
}
}
}
}
}
}
Discovery needs no key. Ratings and market analysis are Pro.
Get an API key
Free tier, no form to fill in. Signing in shares your email address with us — we
store it to create your key and to recognise you if you sign in with another
provider. See our Privacy Policy and
Terms.