Apprise 1.13 shipped on Thursday and it is the final release of the 1.x series. If you use Apprise anywhere in your alerting, and a lot of self hosted stacks do without ever naming it, the action item is one line in a requirements file: pin apprise below 2.0.0 before the next major release arrives with breaking changes. The release itself adds three notification services, brings AES-GCM encryption to Bark, improves Matrix message splitting and Telegram rich messages, and fixes a set of URL parsing problems that will look familiar to anyone who has passed a password with a slash in it through a notification URL.
The short answer
Apprise 1.13 arrived on Thursday, August twentieth, and closes the 1.x series. All future feature work moves to 2.x, which will introduce breaking changes, so the maintainers recommend pinning to apprise greater than or equal to 1.0.0 and less than 2.0.0. The release adds Pinglet, Trigv and Pingram, brings AES-GCM encryption to Bark, improves Matrix message splitting and Telegram rich messages, and fixes several URL parsing failures.
Apprise is one of those dependencies that arrives without an invitation. You install a self hosted application, it wants to send you a notification, and somewhere in its requirements is a library that speaks to a hundred different services through a single URL. Version 1.13 is the last of its line, and that is worth five minutes of your attention even if you have never typed its name.
The one thing to do
The maintainers are explicit: 1.13 is the final release in the 1.x series, and all future feature releases move to 2.x, which will introduce breaking changes.
The recommended constraint is apprise >=1.0.0, <2.0.0. Put it in your requirements file, your pyproject.toml, your container build, wherever your dependency resolution actually happens.
Security patches for the 1.x branch are expected to continue for roughly one to two years, so this is not a deadline. It is the difference between choosing when you migrate and having a routine dependency bump choose for you.
The second half of that advice matters more than it looks for anyone shipping software that embeds Apprise. If your project declares an unpinned dependency, then on the day 2.0 is published every fresh install of your project gets a major version you have not tested against. The failure will be reported to you, not to Apprise.
What 1.13 actually adds
Three new notification targets: Pinglet, Trigv and Pingram. The last of those replaces NotificationApi, which has been retired, so if you have a notificationapi:// URL in a configuration somewhere it needs changing regardless of your upgrade plans.
Bark notifications now support AES-GCM encryption, which is a meaningful addition for anyone pushing alerts to iOS devices through a self hosted Bark server. Telegram gains rich message support, and Matrix handles the splitting of long messages more sensibly, which matters if you route verbose alert bodies into a room and have watched them arrive truncated or fragmented at awkward boundaries.
Microsoft Workflows webhooks using CU routing now work correctly, and in memory email attachments no longer fail, which affects anyone generating a report in a script and attaching it without writing it to disk first.
The parsing fixes deserve a paragraph
The remaining fixes look like housekeeping and are not. Apprise addressed malformed URL authority parsing, coordinate handling in D-Bus and GLib URLs, Splunk entity ID handling, and wider support for RFC 3986 safe path characters.
Apprise's entire interface is a URL. Everything you configure, including credentials, passes through a parser. When that parser mishandles an authority section or rejects a path character the RFC permits, the result is not an error you notice. It is a notification that does not arrive.
For an alerting tool that is the worst available failure mode, because the absence of a message looks exactly like the absence of a problem. If you have ever had a channel that mysteriously never fires, and concluded the condition simply never triggered, a parsing bug is one of the candidates worth eliminating.
What we would take from this
Pin your alerting dependencies more carefully than your application dependencies. It is a slightly counterintuitive priority, because alerting feels peripheral compared to the code that does the work.
The asymmetry is in how the failures present. When an application dependency breaks, something stops working and you find out immediately. When an alerting dependency breaks, everything appears to be working, right up until the moment you needed to be told otherwise. That is worth a version constraint and an occasional test notification through every channel you claim to have.
Sources and further reading
- Apprise 1.13 Notification Tool Released as Final 1.x Version Ahead of 2.0, Linuxiac, August 22, 2026
- Apprise releases on GitHub
- apprise on PyPI
Frequently asked questions
What is Apprise and why would I have it installed?
Apprise is a Python library and command line tool that sends a notification to more than a hundred services through a single URL syntax. You write something like mailto://, discord://, ntfy:// or matrixs:// and Apprise handles the rest, so a script or an application needs one integration rather than one per destination. It turns up in a great many self hosted projects as a dependency rather than a direct choice, which is exactly why the 2.x warning matters: plenty of people are running it without having decided to.
What do I actually need to do before 2.x lands?
Pin it. The maintainers recommend a constraint of apprise >=1.0.0, <2.0.0 in your requirements so that a routine dependency update cannot pull in a major version with breaking changes. If you package your own tooling, do it now rather than when 2.0 appears, because an unpinned install is what turns a major release into an outage on somebody else's schedule. Security patches for the 1.x branch are expected to continue for roughly one to two years, so pinning buys real time rather than deferring an immediate problem.
What is new in 1.13 itself?
Three new notification targets: Pinglet, Trigv and Pingram, the last of which replaces the retired NotificationApi service. Bark notifications gain AES-GCM encryption. Telegram supports rich messages, Matrix handles the splitting of long messages more sensibly, and Microsoft Workflows webhooks that use CU routing now work. On the fix side, there are corrections for in memory email attachments failing, Splunk entity ID handling, malformed URL authority parsing, coordinates in D-Bus and GLib URLs, and wider support for RFC 3986 safe path characters.
Why do the URL parsing fixes matter more than they sound?
Because Apprise's entire interface is a URL, every parsing edge case is a delivery failure. A malformed authority section, a password containing a reserved character, or a path with characters that RFC 3986 permits but the parser did not accept, all produce the same outcome: the notification silently does not arrive. That is the worst failure mode an alerting tool can have, since nobody notices a missing alert until the thing it was meant to warn about has already happened.
When is Apprise 2.0 due and what breaks?
No date has been given. The maintainers have said only that all future feature releases move to the 2.x line and that it will introduce breaking changes requiring adaptation in software that embeds Apprise. The absence of a date is the argument for pinning now. Beyond that, 1.13 also brings improved CLI documentation, proxy information in the man pages, updated GitHub Actions workflows, test suite fixes and a new Italian translation.