Reference · built on requestConnectorMessaging & notifications

Pushover

Push notifications to iOS, Android, and desktop devices through the Pushover Message API, with emergency receipts and callbacks.

About

Pushover is a push notification service from Pushover, LLC for iOS, Android, and desktop clients. An application registered with Pushover gets a 30-character API token. A POST to https://api.pushover.net/1/messages.json with that token, a user or group key, and a message queues a notification. Priority runs from -2 to 2; emergency priority repeats until someone acknowledges and returns a receipt you can poll or have called back.

Through Fibric, an operator proposes a message for a person or delivery group when a condition it watches is met. You approve. The message is sent once, the receipt is stored, and the acknowledgement is recorded against the case.

This is a reference listing. It documents what Fibric would read from Pushover and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Acknowledgement state of an emergency message through GET /1/receipts/{receipt}.json: acknowledged, acknowledged_by, acknowledged_by_device, last_delivered_at, and expired
  • Acknowledgement callbacks POSTed to your callback URL with receipt, acknowledged_at, acknowledged_by, and acknowledged_by_device
  • Monthly message limit, remaining count, and reset time through GET /1/apps/limits.json and the X-Limit-App-Limit, X-Limit-App-Remaining, and X-Limit-App-Reset headers
  • Whether a user or group key is valid and has an active device, with device names and licensed platforms, through POST /1/users/validate.json
  • The request id returned with every API call, kept with the record for support and audit

Proposed actions

  • Target capability: propose a message to a user key, group key, or up to 50 user keys through POST /1/messages.json with title, priority, and ttl
  • Target capability: propose an emergency-priority message with retry and expire, so it repeats until acknowledged
  • Target capability: propose cancelling emergency retries early through POST /1/receipts/{receipt}/cancel.json or by tag through /1/receipts/cancel_by_tag/{tag}.json
  • Target capability: propose creating a delivery group or changing its members through the Groups API at /1/groups.json
  • Target capability: propose a widget update of title, text, subtext, count, or percent through POST /1/glances.json

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Page the person who can act on an alarm

    When a building alarm needs a human, the operator proposes an emergency-priority message to the on-call group. The first acknowledgement cancels retries for everyone else and is written to the alarm record.

    With Alarm Triage

  • Escalate a leak until someone confirms

    A leak sensor reading becomes a proposed emergency message with retry and expire set. If the receipt shows expired with no acknowledgement, the operator proposes the next group.

    With Leak Response

  • Warn on a cold room drifting out of range

    A temperature excursion becomes a proposed high-priority message that bypasses quiet hours, with the reading and a link to the sensor. Readings back in range go out at low priority.

    With Cold Room Watch

  • Nudge on a door held open

    A door held open past its threshold becomes a proposed normal-priority message with a ttl, so it deletes itself from devices once the moment has passed.

    With Door Held Open

Requirements

  • A Pushover application registered under your account, which supplies the API token
  • The user key or delivery group key of each recipient, and optional device names
  • A publicly reachable HTTP or HTTPS callback URL if you want acknowledgements pushed rather than polled
  • Recipients with a Pushover client on at least one active device; validation confirms this before the first send
Authentication
An application API token from registering an application at pushover.net, sent as the token parameter, plus each recipient's user or group key; there is no OAuth.

Limits

  • Messages are limited to 1024 UTF-8 characters, titles to 250, supplementary URLs to 512, and URL titles to 100
  • Each account may send 10,000 messages per month free and teams 25,000; over the quota, every application gets 429 until the 1st of the month
  • Emergency messages retry no more often than every 30 seconds, expire within 10800 seconds, and stop after 50 retries
  • No more than 2 concurrent connections; receipts may be polled no faster than every 5 seconds and only for 1 week

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Pushover ↗

Questions and answers

Can a person acknowledge a Pushover message?
Only emergency-priority messages, sent with priority 2 plus retry and expire. The API returns a receipt. Poll /1/receipts/{receipt}.json or give a callback URL, and Pushover POSTs the acknowledgement with who acknowledged and on which device. Retries stop for the whole group after the first acknowledgement.
Does Pushover have an inbound or read API?
The Message API is send-only. Reads cover receipts for emergency messages, key validation through /1/users/validate.json, monthly limits through /1/apps/limits.json, and delivery group membership through the Groups API. Replies from recipients are not part of this listing.
What counts against the monthly quota?
One successful messages API call to one user, whatever the number of devices on that account. A message to a group key counts once per user in the group. Limits reset at 00:00:00 Central Time on the 1st, and the X-Limit-App-Remaining header shows what is left.
Ask about Pushover

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.