Notification delivery from event to recipient

Notification delivery connects a source event to a selected recipient through processing and provider stages, each with its own completion evidence.

A notification starts with information worth delivering and ends with some intended recipient outcome. Between those points, an integration selects recipients, formats content and invokes a delivery service.

Emby webhooks can supply an event for such a workflow. The webhook's successful delivery is only one stage of the resulting notification.

Which stage completed?

Observation What it establishes
Source event produced The trigger exists
Receiver accepted the event Its accepted-processing boundary was reached
Notification intent stored Work is recorded for later processing
Provider accepted the send The provider accepted that request
Device received or displayed it That particular downstream delivery state was observed
User read it A separate recipient action, when the channel supplies that evidence

A provider's successful API response does not universally mean that a phone displayed an alert. Device connectivity, channel settings and recipient behavior can affect later stages.

Repeated input should preserve one intended notification

An original design uses event E1 plus recipient R1 to identify notification intent N1. Receiving E1 twice should not automatically create N1 and another independent N2 for the same intended action.

A durable intent record and the provider's applicable idempotency contract can help coordinate retries. If the provider offers no duplication guarantee, a response lost after acceptance can leave uncertainty.

For multiple recipients, the result can split: R1's send succeeds while R2's fails. One global “event processed” flag is insufficient if the workflow needs separate recovery for each recipient.

Preferences and permissions are part of selection

Who should receive the message, for which event and with what detail? Those choices depend on the configured integration and recipient preferences.

A media-server user ID does not automatically grant permission to send to every address or device in another service. The destination credential and recipient mapping have their own roles.

When a notification is missing, inspect the last completed stage rather than repeatedly firing the entire workflow. A rejected destination credential, filtered recipient, provider refusal and offline device call for different handling.

See Also

References