# notifiers: 18 providers, one interface, and a release that stopped in May 2025

> A Python library that wraps many notification providers behind one call, plus a CLI and a logging handler. The packaging is where the interesting detail sits: the version string has not moved since v1.3.6 while the branch has, the manifest promises extras that are not declared, and the Makefile builds documentation and nothing else.

**liiight/notifiers** — The easy way to send notifications

- Repository: https://github.com/liiight/notifiers
- Website: http://notifiers.readthedocs.io/
- Stars: 2,736 · Forks: 110
- Language: Python
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/liiight-notifiers

## The version has not moved since v1.3.6, but the branch has

The newest published release is v1.3.6 from 2025-05-17. Before it came 1.3.0 in August 2021 and 1.2.0 in July 2019, so the gap between the last two tags was nearly four years and the gap since the last one is about sixteen months. The manifest still reads `version = "1.3.6"`, and the default branch was last pushed on 2026-09-28. That combination matters practically: a plain `pip install notifiers` installs the 2025 build, while the source tree in the repository is a year newer and carries files the tag may not have. The wheel and sdist include lists name the same three paths, `notifiers`, `notifiers_cli` and `LICENSE`, and the sdist additionally excludes `tests`, so even the source distribution does not carry the suite that guards the provider code.

## The interpreter floor is 3.8, the classifiers start at 3.9, the image is 3.13

Three numbers describe supported Python and none of them agree. The manifest sets `requires-python = ">=3.8"`, the classifier list covers 3.9 through 3.13 and stops there, so the oldest version the project claims to support has no classifier of its own and nothing covers 3.14. The container image is built from `ghcr.io/astral-sh/uv:python3.13-alpine`, so the shipped runtime is the newest version the classifiers mention rather than the oldest. Everything else in the metadata is conservative in the other direction: `Operating System :: OS Independent`, `Intended Audience :: Developers` and `Intended Audience :: End Users/Desktop`, and a `Development Status :: 5 - Production/Stable` classification on a project whose last release predates the current Python minor versions.

## The README names three dependencies, the manifest lists four, and two links point below the minimums

The advantages section sells a minimal set of well known and stable dependencies and names three of them, with links to their PyPI pages. The manifest lists four. Besides requests, jsonschema and click there is `importlib-metadata>=3.6`, the package that backports package metadata to interpreters older than 3.8, which is the very version the manifest sets as its floor. The links are older than the requirements too: the jsonschema link points at the 2.6.0 page while the manifest demands `jsonschema>=4.4.0`, and the click link points at 6.7 while the manifest demands `click>=8.0.3`. Only one entry carries an upper bound, `requests>=2.27.1,<3`, so the HTTP layer is the only dependency with a stated ceiling.

## One introspection method, one call, and a CLI that mirrors both

The library's whole shape fits in four lines of a REPL session:

```python
>>> from notifiers import get_notifier
>>> p = get_notifier('pushover')
>>> p.required
{'required': ['user', 'message', 'token']}
>>> p.notify(user='foo', token='bar', message='test')
<NotificationResponse,provider=Pushover,status=Success>
```

Ask a provider what it needs and it answers with the key names, which is what makes a single interface possible across eighteen services. There is a functional shortcut for the same thing, `notify('pushover', user='foo', token='bar', message='test')`, and the command line takes the same keys as options:

```text
$ notifiers pushover notify --user foo --token baz "This is so easy!"
```

The order is provider, action, required keys as flags, then the message last. The supported list spans push services, chat platforms, mail over SMTP, and incident tools, among them Pushover, SimplePush, Slack, Gmail, Telegram, Gitter, Pushbullet, Join, Zulip, Twilio, Pagerduty, Mailgun, PopcornNotify, StatusPage.io, iCloud, VictorOps and Notify.

## The logging handler reuses the provider's own required keys as defaults

Rather than asking users to assemble a payload for every call site, the library ships a handler for the standard library's logging module:

```python
>>> import logging
>>> from notifiers.logging import NotificationHandler

>>> log = logging.getLogger(__name__)

>>> defaults = {
        'token': 'foo',
        'user': 'bar'
    }
>>> hdlr = NotificationHandler('pushover', defaults=defaults)
>>> hdlr.setLevel(logging.ERROR)

>>> log.addHandler(hdlr)
```

The defaults dictionary is keyed by the same names `required` reports, `user` and `token` for Pushover, so the contract between the introspection call and the handler is the shared key vocabulary rather than a separate configuration format. Level filtering stays with logging itself, which is why the example sets ERROR before attaching: a handler that only accepts certain providers still routes whatever the logger emits at or above that level. One consequence is that credentials live in a dict in the calling module, with no environment variable path offered in the documented usage.

## The roadmap promises extras, and the manifest declares no extras at all

Two items sit under the road map heading: many more providers, and low level providers, naming Amazon SNS, Google FCM and operating system toast messages, to be delivered through `extra` dependencies. The manifest has no optional dependency table. What it does have is a dependency group for development, holding pytest, pytest-cov, codecov, hypothesis, retry, pre-commit, Sphinx and the rtd theme, and a pytest marker named `online` whose description is that it marks tests running online, which is how a provider library tests itself against real services rather than recorded responses. Packaging is hatchling for both wheel and sdist, and a lock file sits in the tree, which matches the container build that syncs dependencies with uv before dropping to an unprivileged user.

## The Makefile builds documentation and routes every unknown target to Sphinx

The Makefile in this repository has one job. It defines the Sphinx variables and a help target, then ends with a catch all:

```make
SPHINXBUILD   = python -msphinx
SOURCEDIR     = source
BUILDDIR      = docs
```

Any target not defined explicitly is handed to `sphinx -M`, with the documentation source in `source` and output in `docs`, and a `make.bat` sits beside it for Windows. There is no test target and no lint target in that file, even though the tree holds a `ruff.toml` and a `.pre-commit-config.yaml`, so the checks live outside make. The documentation links are also split by scheme: the README and the repository metadata point at readthedocs over plain http, including the changelog link, while the manifest's documentation field uses https.

## Conclusion

notifiers earns its place when a script or service needs to notify through whatever channel the operator already uses, and its design holds up: one required-keys introspection method, one call, one result object carrying provider and status, and a logging handler that reuses the same keys. It is not the place to start if you need typed provider SDKs, per-provider features, or delivery guarantees, because the abstraction is deliberately thin and the response object reports status rather than retrying. Before adopting, check which version you would actually get: the newest release is v1.3.6 from 2025-05-17 while the default branch was pushed on 2026-09-28, so a normal install is roughly a year behind the repository. Also note that Python 3.8 is the declared floor but the classifiers start at 3.9, that the test suite carries an online marker for tests that hit live services, and that the roadmap's low level providers are described as extras that the manifest does not define.

## FAQ

### What is notifiers used for in Python?

It is a one stop library for sending notifications through many providers behind one interface, so a script or service does not need a separate client library per service. There are two Python entry points, get_notifier and notify, a notifiers command line, and a NotificationHandler for the standard logging module.

### Which notification providers does notifiers support?

The README lists eighteen, including Pushover, SimplePush, Slack, Gmail, plain email over SMTP, Telegram, Gitter, Pushbullet, Join, Zulip, Twilio, Pagerduty, Mailgun, PopcornNotify, StatusPage.io, iCloud, VictorOps for Splunk and Notify.

### How is notifiers installed?

With pip install notifiers, brew install notifiers, or by pulling the image liiight/notifiers from Docker Hub. The container is built from ghcr.io/astral-sh/uv:python3.13-alpine, syncs its dependencies with uv and sets the notifiers command as its entrypoint.

### How do I find out which arguments a notifiers provider needs?

Ask the provider object. Calling get_notifier('pushover') and then .required returns the key names as a dict of required fields, for Pushover user, message and token. The command line takes the same names as options, after the provider name and the notify action.

### Can notifiers send from a Python logger?

Yes. notifiers.logging.NotificationHandler takes a provider name and a defaults dictionary keyed by that provider's required fields, you set a level with setLevel and then add the handler to a logger. The documented example attaches a Pushover handler at ERROR level.

## Sources

- [License: MIT](https://github.com/liiight/notifiers/blob/main/LICENSE)
- [liiight/notifiers on GitHub](https://github.com/liiight/notifiers)
- [Project website](http://notifiers.readthedocs.io/)
- [README](https://github.com/liiight/notifiers/blob/main/README.md)
- [Releases](https://github.com/liiight/notifiers/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/liiight-notifiers