Send notification to recipient (async, queued)

Who to wake up. The channel is NOT chosen here — it comes from that person's notification settings for the priority below.

Three failures worth telling apart, because they answer differently. A uuid that exists nowhere is a 422. A uuid belonging to another company passes the existence check and then fails to resolve inside your tenant, so it comes back as 404 — same as a typo would look, and not the 403 you might expect. And a recipient of yours who is deactivated is not refused at all: the send proceeds, and whether anything leaves depends on the routes their settings produce. Do not read a 2xx here as "this person is reachable"; read GET /recipients/{recipient}/availability for that.

The alert text, as the person will read it. On a voice channel it is also what gets spoken: the text is synthesised to speech and cached, so the same wording costs the synthesiser only once. Keep it self-contained — a human woken at 4am sees this and nothing else.

Which of the recipient's four notification settings applies — that is what actually picks the channel, the escalation ladder, and whether quiet hours are bypassed. Not a label: critical and low can route to entirely different providers. Defaults to normal when omitted.

Path to a ready-made audio file in this installation's storage, for voice channels. An API client normally has no such path and should omit this: the voice is then synthesised from message. A path that does not resolve is not an error — it is logged and the text is synthesised instead, so a typo here costs a delay, not a lost alert.

How many delivery attempts one channel may make before the step is considered failed. Defaults to 3 when omitted. This is retrying the SAME channel, not escalation: handing the alert to the next person is the escalation ladder's job and is configured on the recipient, not here.