Pushover Notifications

Overview

• Source: https://pushover.net/
• Image Support: No
• Attachment Support: Yes
• Message Character Limits:
  • Body: 512
• Build Your Apprise URL

Account Setup

There isn’t too much configuration for Pushover notifications. The message is basically just passed to your online Pushover account and then gets relayed to your device(s) you’ve setup from there.

Getting Your User Key

Once you log into the website, your dashboard will present your {user_key} in front of you.

Getting Your API Token

On the dashboard after logging in, if you scroll down you’ll have the ability to generate an application. Upon doing so, you will be provided an API Token to associate with this application you generated. This will become your {token}.

Syntax

Valid syntax is as follows:

• pover://{user_key}@{token}
• pover://{user_key}@{token}/{device_id}
• pover://{user_key}@{token}/{device_id1}/{device_id2}/{device_idN}
• pover://{user_key}@{token}/#{group_key}
• pover://{user_key}@{token}/{device_id}/#{group_key}
• pover://{user_key}@{token}?priority={priority}
• pover://{user_key}@{token}?priority=emergency&expire={expire}&interval={interval}
• pover://{user_key}@{token}?key={encryption_key}
• pover://{user_key}@{token}?key={encryption_key}&e2ee=no

Parameter Breakdown

Variable	Required	Description
user_key	Yes	The user key identifier associated with your Pushover account. This is NOT your email address. The key can be acquired from your Pushover dashboard.
token	Yes	The token associated with your Pushover account.
device_id	No	The device identifier to send your notification to. By default if one isn’t specified then all of devices associated with your account are notified.
group_key	No	A Pushover delivery group key, prefixed with #. Group keys look identical to user keys and allow broadcasting a message to all members of a group with a single key. Multiple groups may be specified. Groups and devices can be mixed in the same URL.
priority	No	Can be low, moderate, normal, high, or emergency; the default is normal if a priority isn’t specified. To send an emergency-priority notification, the interval and expire parameters should be supplied. You may also set the priorities as documented on the Pushover API where -2 is low, -1 is moderate, 0 is normal, 1 is high and 2 is emergency
expire	No	The expire parameter specifies how many seconds your notification will continue to be retried for (every interval seconds). If the notification has not been acknowledged in expire seconds, it will be marked as expired and will stop being sent to the user. Note that the notification is still shown to the user after it is expired, but it will not prompt the user for acknowledgement. This parameter has a maximum value of at most 10800 seconds (3 hours). The default is 3600 seconds (1 hr) if nothing is otherwise specified.
interval	No	Specifies how often (in seconds) the Pushover servers will resend the same emergency notification to the user. In a situation where your user might be in a noisy environment or sleeping, retrying the notification (with sound and vibration) will help get his or her attention. This parameter must have a value of at least 30 seconds between retries. The default is 900 seconds (15 minutes) if nothing is otherwise specified. Note: this is distinct from Apprise’s own retry mechanism which controls how many times Apprise re-attempts a failed delivery.
sound	No	Can optionally identify one of the optional sound effects identified here. The default sound is pushover.
url	No	Can optionally provide a Supplementary URL to go with your message
url_title	No	Can optionally provide a Supplementary URL Title to go with your message
key	No	A 64-character hexadecimal string representing a 256-bit AES key used for end-to-end encryption. When set, the message, title, url, and url_title fields are each encrypted client-side before being transmitted. Requires the cryptography Python package (pip install cryptography). If the package is absent, Apprise falls back to sending the message unencrypted with a warning.
e2ee	No	Controls whether end-to-end encryption is applied when a key is configured. Defaults to yes. Set to no to temporarily send plaintext even when a key is present.

Global Parameters

Variable	Description
overflow	This parameter can be set to either split, truncate, or upstream. This determines how Apprise delivers the message you pass it. By default this is set to upstream 👉 upstream: Do nothing at all; pass the message exactly as you received it to the service. 👉 truncate: Ensure that the message will fit within the service’s documented upstream message limit. If more information was passed then the defined limit, the overhead information is truncated. 👉 split: similar to truncate except if the message doesn’t fit within the service’s documented upstream message limit, it is split into smaller chunks and they are all delivered sequentially there-after.
format	This parameter can be set to either text, html, or markdown. Some services support the ability to post content by several different means. The default of this varies (it can be one of the 3 mentioned at any time depending on which service you choose). You can optionally force this setting to stray from the defaults if you wish. If the service doesn’t support different types of transmission formats, then this field is ignored.
verify	External requests made to secure locations (such as through the use of https) will have certificates associated with them. By default, Apprise will verify that these certificates are valid; if they are not then no notification will be sent to the source. In some occasions, a user might not have a certificate authority to verify the key against or they trust the source; in this case you will want to set this flag to no. By default it is set to yes.
redirect	By default, Apprise will follow HTTP redirects (3xx responses) issued by the remote server, matching the behaviour of the underlying requests library. If you want to prevent custom headers and credentials from being forwarded to destinations that differ from the original URL, set this to no. By default it is set to yes.
cto	This stands for Socket Connect Timeout. This is the number of seconds Requests will wait for your client to establish a connection to a remote machine (corresponding to the connect()) call on the socket. The default value is 4.0 seconds.
rto	This stands for Socket Read Timeout. This is the number of seconds the client will wait for the server to send a response. The default value is 4.0 seconds.
emojis	Enable Emoji support (such as providing :+1: would translate to 👍). By default this is set to no. Note: Depending on server side settings, the administrator has the power to disable emoji support at a global level; but default this is not the case.
tz	Identify the IANA Time Zone Database you wish to operate as. By default this is detected based on the configuration the server hosting Apprise is running on. You can set this to things like America/Toronto, or any other properly formated Timezone describing your area.
retry	The number of additional delivery attempts to make after the first failure before giving up. Accepts an integer in the range 0 to 10. The default is 0 (no retries — a single attempt is made). When combined with wait, Apprise pauses the specified number of seconds between each attempt.
wait	The number of seconds to pause between retry attempts. Accepts a decimal value in the range 0.0 to 20.0; integer values are promoted to float automatically. The default is 0.5. This value is only meaningful when retry is greater than zero — a service with retry=0 makes exactly one attempt regardless of the wait value.
optional	When set to yes, a delivery failure for this service is silently absorbed. The overall notify() call still returns True even if this endpoint was unreachable, provided that every required (non-optional) service in the same batch succeeded. Setting this flag does not skip delivery or bypass retry logic — all configured retry attempts are still made before the failure is absorbed. By default this is set to no, meaning every failure is propagated to the caller.

End-to-End Encryption (E2EE)

When E2EE is enabled, the message content is encrypted on the Apprise side before being sent — Pushover’s servers never see the plaintext. Only devices that have been configured with the same key can decrypt and display the notifications.

Step 1 — Generate Your Key

You create the encryption key yourself. It is a random 256-bit value represented as a 64-character hexadecimal string. Run one of the commands below to generate one:

Linux / macOS

python3 -c "import secrets; print(secrets.token_hex(32))"

Windows (PowerShell)

[System.BitConverter]::ToString(
    [System.Security.Cryptography.RandomNumberGenerator]::GetBytes(32)
).Replace("-", "").ToLower()

This uses .NET’s cryptographically secure random number generator, built into both Windows PowerShell 5.1 and PowerShell 7+. No extra modules are required.

Copy the 64-character output. That string is your encryption key. Store it somewhere safe — you will need it again in the next step and any time you set up a new device.

Step 2 — Configure the Key in Each Pushover Device

Mobile only

E2EE decryption is supported on the iOS and Android Pushover apps (v5.0+) only. Desktop clients (browser, macOS, Windows) do not support E2EE and will not have an encryption setting. If you only use Pushover on desktop, skip this feature.

Every iOS or Android device that should display the decrypted notifications must be configured with the same key. Open the Pushover app, navigate to its Settings, and look for an Encryption or End-to-End Encryption option. Paste your 64-character hex key into the field and save.

Repeat this on every phone or tablet where you receive Pushover notifications. Any device that does not have the key configured will display the notification as unreadable encrypted text.

Note

E2EE support on Android was introduced in Pushover v5.0 (released May 2026). If you cannot find the encryption setting on Android, update the app from the Play Store first. If the option is still missing after updating, contact Pushover support.

Note

If you later generate a new key, you must update it in both the Pushover app on every device and your Apprise URL.

Step 3 — Add the Key to Your Apprise URL

Append ?key= followed by your 64-character hex string to the Pushover URL:

pover://{user_key}@{token}?key={your-64-char-hex-key}

See the Examples section below for a full working command.

Requirements

E2EE requires the cryptography Python package. Install it with:

pip install cryptography

If the package is not installed and a key is configured, Apprise logs a warning and sends the message unencrypted as a graceful fallback. Set e2ee=no to intentionally send plaintext while keeping the key stored in the URL for future use.

Caution

Store your encryption key securely. Anyone with the key can decrypt the notifications. Treat it with the same care as your API token.

Custom Sounds

Pushover integration constrains notification sounds to a predefined list. This change adds support for custom sound in notifications, which must be uploaded and given a name. This change updates the pushover integration to allow for that name to be specified instead of throwing an error.

1. Go to Settings -> Alert Settings -> Manage custom sounds -> Upload a sound
2. Upload a sound and specify a name (e.g. “mysound”).
3. Validate the sound is accessible and present in the sounds list for your app via https://api.pushover.net/1/sounds.json?token={app-token}
4. Specify a sound in your pover call, i.e. apprise -vv -t "title" -b "test message" pover://user@app?sound=mysound

You should hear your custom sound on the notification. In cases where the custom sound name is not found, the default pushover notification sound will play.

Examples

Send a Pushover notification to all of our configured devices:

# Assuming our {user_key} is 435jdj3k78435jdj3k78435jdj3k78
# Assuming our {token} is abcdefghijklmnop-abcdefg
apprise -vv -t "Test Message Title" -b "Test Message Body" \
   pover://435jdj3k78435jdj3k78435jdj3k78@abcdefghijklmnop-abcdefg

Send a Pushover notification to a delivery group:

# Assuming our {user_key} is 435jdj3k78435jdj3k78435jdj3k78
# Assuming our {token} is abcdefghijklmnop-abcdefg
# Assuming our {group_key} is gznej3rKEVAvPUxu9vvNnqpmZpokzF
# The # prefix identifies it as a group key
apprise -vv -t "Test Message Title" -b "Test Message Body" \
   "pover://435jdj3k78435jdj3k78435jdj3k78@abcdefghijklmnop-abcdefg/#gznej3rKEVAvPUxu9vvNnqpmZpokzF"

Send a Pushover notification with the Emergency Priority:

# Emergency priority advises you to also specify the expire and
# interval values.
# Assuming our {user_key} is 435jdj3k78435jdj3k78435jdj3k78
# Assuming our {token} is abcdefghijklmnop-abcdefg
# The following will set a 1hr expiry and attempt to resend
# the message every 10 minutes:
apprise -vv -t "Test Message Title" -b "Test Message Body" \
   pover://435jdj3k78435jdj3k78435jdj3k78@abcdefghijklmnop-abcdefg?priority=emergency&interval=600&expire=3600

Send an end-to-end encrypted Pushover notification:

# Assuming our {user_key} is 435jdj3k78435jdj3k78435jdj3k78
# Assuming our {token} is abcdefghijklmnop-abcdefg
# Assuming our 64-char hex encryption key is aabbcc...
# (generate one with the commands in the section above)
apprise -vv -t "Test Message Title" -b "Test Message Body" \
   "pover://435jdj3k78435jdj3k78435jdj3k78@abcdefghijklmnop-abcdefg?key=aabbccdd11223344aabbccdd11223344aabbccdd11223344aabbccdd11223344"