Notifications and responses

A notification is one actionable execution.
It can be created by an Automation, a Reminder, or directly through the API, and it owns its delivery attempts, provider receipts, response capability, and terminal state.

Direct callers send idempotency_key, title, and message to
POST /v1/notifications. They may also send source context and delivery-policy
overrides. Omitted policy fields use Anchor and account defaults. The first
request returns 201, an identical replay returns 200, and conflicting reuse
of the idempotency key returns 409.

Direct callers may configure the same gradual urgency policy as Automations
with important_escalation_threshold and
emergency_escalation_threshold. Thresholds mean “starting with notification
#N,” must be ordered, and cannot exceed maximum_prompts. A Routine-to-
Emergency policy must include the intermediate Important stage.

The origin field is automation, reminder, or api.
automation_id is present only for Notifications created by an Automation, and reminder_id is present while its Reminder definition still exists.

Available actions

• Acknowledge confirms that you saw the notification.
• Complete records that the requested work is finished.
• Snooze pauses the current escalation step and replays it later at the same urgency.
  The replay does not consume another escalation step.
  If it is ignored, normal escalation continues after it.
• An explicit Snooze time bypasses Anchor quiet hours and the Automation’s delivery window.
  When a deadline exists, the selected time must be strictly before it; snoozing never extends the deadline.
• Snooze remains available at the final escalation step.
  Without a deadline, that final step may be snoozed repeatedly.
  If its replay is ignored, the Notification becomes Missed when the final cycle finishes.
• Skip closes the notification without completing it.
• Cancel administratively stops an active notification from the authenticated app or API.

The actions shown depend on the automation and current state. Repeating an already-applied action is safe and returns the resulting state.

Secure response links

Pushover links contain the secret response token in the URL fragment. Browsers do not send that fragment in the initial HTTP request. The response page keeps the token in memory and sends it only in the dedicated Anchor response-token header.

Expired or invalid links do not reveal notification details. A terminal link can show the final state without reopening the notification.