Skip to main content
https://github.com/Kinto/kinto-emailer/actions/workflows/tests.yml/badge.svg https://img.shields.io/pypi/v/kinto-emailer.svg

kinto-emailer send emails when some events arise (e.g. new records have been created). It relies on Pyramid Mailer for the sending part.

Install

pip install kinto-emailer

Setup

In the Kinto settings:

kinto.includes = kinto_emailer

mail.default_sender = kinto@restmail.net

# mail.host = localhost
# mail.port = 25
# mail.username = None
# mail.password = None
# mail.tls = False
# mail.queue_path = None

If mail.queue_path is set, the emails are storage in a local Maildir queue.

See more details about Pyramid Mailer configuration.

Validate configuration

The following command will send a dummy email to the specified recipient or will fail if the configuration is not correct:

$ kinto-send-email config/kinto.ini testemailer@restmail.net

Development

Use a fake emailer that write emails files to disk:

mail.debug_mailer = true

How does it work?

Some information — like monitored action or list of recipients — are defined in the collection or the bucket metadata. When an event occurs, the plugin sends emails if one of the expected condition is met.

Usage

The metadata on the collection (or the bucket) must look like this:

{
  "kinto-emailer": {
    "hooks": [{
      "template": "Something happened!",
      "recipients": ['Security reviewers <security-reviews@mozilla.com>']
    }]
  }
}

In the above example, every action on the collection metadata or any record in that collection will trigger an email notification.

The metadata of the collection override the bucket metadata, they are not merged.

Optional:

  • subject (e.g. "An action was performed")

  • sender (e.g. "Kinto team <developers@kinto-storage.org>")

Recipients

The list of recipients can either contain:

  • Email adresses (eg. alice@wonderland.com or "Joe Doe <jon@doe.com>")

  • Group URI (eg. /buckets/staging/groups/reviewers)

With group URIs, the email recipients will be expanded with the group members principals look like email addresses (eg. ldap:peace@world.org).

Selection

It is possible to define several hooks, and filter on some condition. For example:

{
  "kinto-emailer": {
    "hooks": [{
      "resource_name": "record",
      "action": "create",
      "template": "Record created!",
      "recipients": ['Security reviewers <security-reviews@mozilla.com>']
    }, {
      "resource_name": "collection",
      "action": "updated",
      "template": "Collection updated!",
      "recipients": ["Security reviewers <security-reviews@mozilla.com>"]
    }]
  }
}

The possible filters are:

  • resource_name: record or collection (default: all)

  • action: create, update, delete (default: all)

  • collection_id (default: all)

  • record_id (default: all)

  • event: kinto.core.events.AfterResourceChanged (default), or kinto_remote_settings.signer.events.ReviewRequested, kinto_remote_settings.signer.events.ReviewApproved, kinto_remote_settings.signer.events.ReviewRejected

If a filter value starts with the special character ^, then the matching will consider the filter value to be a regular expression.

For example, in order to exclude a specific collection_id, set the filter value to: ^(?!normandy-recipes$).

Template

The template string can have placeholders:

  • bucket_id

  • id: record or collection id

  • user_id

  • resource_name

  • uri

  • action

  • timestamp

  • root_url

  • client_address

  • user_agent

  • settings[name]

For example:

{user_id} has {action}d a {resource_name} in {bucket_id}.

See Kinto core notifications.

Running the tests

To run the unit tests:

$ make tests

Functional Tests

A PostgreSQL database is required.

Install and run PostgreSQL using your system package manager, or using Docker:

$ docker run -e POSTGRES_PASSWORD=postgres -p 5432:5432 postgres:15

Create the test database:

$ psql -c "CREATE DATABASE testdb ENCODING 'UTF8' TEMPLATE template0;" -U postgres -h localhost -p 5432

Run a Kinto instance in a separate terminal:

$ make run-kinto

And start the test suite:

$ make functional

Releasing

  1. Create a release on Github on https://github.com/Kinto/kinto-emailer/releases/new

  2. Create a new tag X.Y.Z (This tag will be created from the target when you publish this release.)

  3. Generate release notes

  4. Publish release

Release files for kinto-emailer 4.0.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for kinto-emailer 4.0.0
File Size Uploaded
kinto_emailer-4.0.0.tar.gz 36.7 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for kinto-emailer 4.0.0
File Interpreter ABI Platform
kinto_emailer-4.0.0-py3-none-any.whl Python 3 none any Details

Total release size: 44.9 kB

Release files / kinto_emailer-4.0.0.tar.gz

Download URL kinto_emailer-4.0.0.tar.gz
Size 36.7 kB
Tags Source
SHA-256 checksum
How to use checksums
df6d32ea799b85a55115590c340329c94c3d1ba1e3f590e897a73a3e37da0e38
BLAKE2b-256 checksum
How to use checksums
6ddb74fb0b572b1416c720317c698b7352ebdea8f6382a677b60b2da5adb6f0a
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.12

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on May 7, 2026.

Transparency log

Release files / kinto_emailer-4.0.0-py3-none-any.whl

Download URL kinto_emailer-4.0.0-py3-none-any.whl
Size 8.2 kB
Tags Python 3
SHA-256 checksum
How to use checksums
013e29f99a0736d078a23dc5cd0a740b44a079b5ef32150f521ffcf66ed64031
BLAKE2b-256 checksum
How to use checksums
98998193f9ffa15a538ae4bcc8853d96336a876b21811e4d6c439058f61d8302
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.13.12

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on May 7, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

4.0.0 This release

2 release files

3.0.4

2 release files

3.0.3

2 release files

3.0.2

2 release files

3.0.1

2 release files

2.1.0

2 release files

2.0.0

1 release file

1.1.0

1 release file

1.0.2

1 release file

1.0.1

2 release files

1.0.0

2 release files

0.4.0

2 release files

0.3.0

1 release file

0.2.0

1 release file

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page