Download the PHP package remp/mailer-module without Composer

On this page you can find all versions of the php package remp/mailer-module. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package mailer-module

Mailer Module

Mailer Module is the core extensible package of the REMP Mailer, which serves as a tool for configuration of mailers, creation of email layouts and templates, and configuring and sending mail jobs to selected segments of users.

Installation

Use composer to install the package:

In Bootstrap.php file (where Nette Configurator is initialized), add module's config.root.neon file as the first configuration file:

Configuration

Redis

You can configure default Redis keys prefix, which is used if implementation using RedisClientTrait enables prefixing via useRedisKeysPrefix() method.

You can then turn on prefixing for specific service (using RedisClientTrait) by calling useRedisKeysPrefix() method in configuration.

Permission management

You can setup and control privileges for different roles by calling these setup method calls in your configuration file:

If you don't register privilege to any role, it's allowed for everyone by default because of backward compatibility.

List of allowable privileges:

resource privilege description
batch start Allows user to start sending mail batch.
batch stop Allows user to stop sending mail batch.
batch process Allows user to process mail batch.

Email's localization

You can add support for another languages by adding array of secondary locales in the configuration of localization service:

Default locale is setted by using .env variable LOCALE.

Email allow list

Mailer supports allow listing email addresses to prevent sending emails to unwanted email addresses. This feature is not active by default. To activate allow list you have to specify one or more allowed email addresses in application configuration:

To allow all email addresses from specified domain you have to use double @ because Nette handles single @ as reference to other service.

Allowed domain manager

Mailer adds RTM parameters to links found in outgoing emails. To control to which links RTM parameters are added you have to specify allowed domains. RTM parameters are only added to links that match all domain levels with one of the allowed domains.

Email template service parameters

Mailer allows adding service parameters to mail templates, that are available to use in every email. To bind your own parameters, you have to register ServiceParamsProviderInterface implementation in which you can add your own parameters.

Registration example:

Mailer module is by default adding two parameters (settings and unsubscribe) in DefaultServiceParamsProvider. If u register your own service params provider, default one will not be used. You can extend DefaultServiceParamsProvider instead of implementing ServiceParamsProviderInterface to preserve binding default service parameters.

Technical feature description

Mailers setup

You can setup multiple mailers to send emails with. Use code in addMailer function (see example) to differentiate between mailers of the same type. In the settings you have to provide necessary values for each mailer.

Newsletter lists

Lists represent categories of emails (newsletters). Their primary (and only) use case is to group single emails within a newsletter and manage subscriptions of users to these newsletters.

When you create a new newsletter, you can specify:

Any handling of subscription/unsubscription of end users from newsletters is handled via API. Publishers mostly want to have this included within the customer zone of their systems - designed consistently with the rest of their system. Therefore, Mailer doesn't provide any user-facing frontend.

To see the APIs to integration subscription management, see Managing user subscription section.

Emails and Layouts

Emails and layouts provide a way how to manually create emails with the possibility to see realtime preview of the email while doing so. As the names suggest:

HTML version can be edited by CodeMirror editor (html, default) or Trumbowyg editor (WYSIWYG). Default editor can be changed using .env variable TEMPLATE_EDITOR. (options: codemirror, wysiwyg)

Text and HTML versions of email support Twig syntax and you can use standard Twig features in your templates. Mailer is able to provide custom variables to your templates. These can originate from different sources:

Note: Mailer doesn't verify presence of the variable nor does it currently provide fallback value. If you use the custom variable and it won't be present in the IUser response, empty string will be injected into your email body.

Saving the email doesn't trigger any sending. It creates an instance of email that might be sent manually (or by 3rd parties) via API or as a batch within a Mailer's job.

Jobs

Jobs can be understood as a newsletter sending orders. They can consist of smaller batches which provide their own statistics. This is useful when you want to run an A/B test on smaller batch, evaluate and send the email to rest of the users.

When creating a job, you implicitly create also its first batch. The job has only one option shared across all batches:

All the other options are related to the batch that is created with the job. Afterwards you'll be able to create more batches within the job if necessary.

When the job/batch is created, you need to either push "Start sending" or "Prepare queue" button. After pressing both buttons, the background processor will receive necessary information about target group of users and prepare metadata for sending daemon.

Once the metadata is ready, when pressed "Start sending" button, the batch will be picked up by sending daemon and actual emails will be sent via preconfigured Mailer (SMTP, Mailgun, ...). When "Prepare queue" button was pressed, the batch is in the processed state, all the metadata is prepared and the number of emails that will be actually sent is available.

You can create and execute jobs/batches programmatically by using provided API endpoints.

To remove old batches that are in the processed state use mail:remove-old-batches command. Batch is considered to be old when it is in the processed state for more than 24 hours. All the metadata prepared when changing state to processed can be outdated, and it is not recommended to use for sending emails.

Generators

Generators are single-purpose implementations that help to generate HTML/text content of emails programmatically based on the provided input. That means that instead of manually preparing email content (HTML to send) every time you want to send an email, you can simplify the creation by implementing custom generator that can do the hard work for you.

For example the generator can require list of URLs to your articles. When it gets them, it will parse the content of the URLs, extracts title, excerpt and image of the article and injects that into the prepared generator template. Person preparing the email has a guarantee that he/she won't create invalid HTML (due to typo) and the whole process is sped up as the only thing he/she needs to enter are article URLs. The flow we just described matches with how ArticleUrlParserGenerator works.

Each prepared generator template is directly linked to a generator implementation. It's therefore guaranteed that the variables used within generator template will always be provided (unless the implementation contains a bug).

Implementing generator

To create a new generator, you need to implement Remp\MailerModule\Generators\IGenerator interface. Methods are described below with references to UrlParserGenerator:

Registering generator

When your implementation is ready, register your generator in config.local.neon. The parameters of registerGenerator method are:

Base flow of actions

Here you can see simplified view of how Mailer works at following diagram.

Integration with user base

Mailer is dependent on external user base and segment provider. After the installation the application uses dummy implementations Remp\MailerModule\Segment\Dummy and Remp\MailerModule\User\Dummy.

To integrate with Mailer you need to provide real implementation of these interfaces against your system responsible for keeping user information. The API definition can be anything that suits you, but in the end the implementation has to process the response and return the data in the structure that's described below.

Segment integration

To determine who to send an email to, Mailer is dependent on user segments - effectively lists of user IDs which should receive a newsletter. You can register as many segment providers as you want, the only condition is that the providers should work with the same user-base (one user ID has to always point to the) same user.

The implementation is required to implement Remp\MailerModule\Models\Segment\ISegment interface.

There are three methods to implement:

Dummy implementation

See the Remp\MailerModule\Models\Segment\Dummy implementation as a reference example.

REMP CRM implementation

See the Remp\MailerModule\Models\Segment\Crm implementation to check how you can initialize your class the dependencies, structure the request and process the result

The constructor accept two parameters. They should come from app/config/config.local.neon file:

User integration

As segments are working only with user IDs, and some of them might not be valid or active anymore, Mailer requires an implementation that returns user information based on the ID.

The implementation is required to implement Remp\MailerModule\Models\Users\IUser interface.

Dummy implementation

See the Remp\MailerModule\Models\Users\Dummy implementation as a reference example.

REMP CRM implementation

See the Remp\MailerModule\Models\Users\Crm implementation to check how you can initialize your class the dependencies, structure the request and process the result

The constructor accept two parameters. They should come from app/config/config.local.neon file:

The response is then fetched as process to match expected structure:

Managing user subscriptions

Mailer keeps the information about which user is subscribed to which newsletter and provides:

The changes Mailer is interested in are:

In case you're not able to call these APIs, you can create console command and synchronize the data against your APIs with your update logic.

If the subscription changes aren't triggered from CRM, it is recommended to notify CRM about changes in user's setting. You can use Hermes worker \Remp\MailerModule\Hermes\NotifyCrmSubscribeUnsubscribeHandler which notifies CRM about the change and refreshes user's cached data. To enable the feature, register the handler in your config.local.neon:

Mailers

By default, the application includes implementation of:

You can select the default mailer on the settings page: http://mailer.remp.press/settings/

Mailer integration

You can add your own implementation of Mailer to the service of your choice.

The implementation is required to extend Remp\MailerModule\Models\Mailer abstract class.

Note: SmtpMailer implementation automatically removes X-Mailer-Template-Params header before sending to prevent leaking of sensitive information.

Event-receiving webhooks

If you're able to configure your 3rd party service to send stats about emails via webhooks, you can create an API handler to receive the stats and process them.

Our Mailgun webhook implementation validates the request and marks the event to be processed later asynchronously.

In case of having multiple mailgun mailers, each webhook URL should have mailer code specified in query params. It is the same code as specified in your config.local.neon

For example, you should use webhook URL https://mailer.remp.press/api/v2/mailers/mailgun?code=us to process events for emails sent by Mailer defined by this configuration:

To add your own API handler and background event processing, create your implementations and register them in config.local.neon file:

Event-fetching commands

If you are able to fetch event statistics from 3rd party service via API, we recommend writing a console command which can be run as daemon fetching the stats as they're generated.

In our experience we find webhooks to be faster and more accurate, however they might cause a higher load on your servers at the time of sending the newsletter.

Our Mailgun events API implementation runs as daemon end fetches the new data every 15 seconds.

Your implementation then needs to be added also to the config.local.neon file:

Once it's ready, you can execute it by calling php bin/command.php mailgun:events. The name of the command (mailgun:events) is defined within your implementation, you can use any namespace and name you want. In case of multiple Mailgun mailers you can set option code to set up command for specific mailer.

Workers

For application to function properly, you need to run several backend workers handling email-sending related tasks.

To list all available console commands, run php bin/command.php.

We recommend to use Systemd or Supervisord for handling them. Following are Systemd configurations.

Background event processing (Hermes worker)

This configures handler of all asynchronous events generated by application.

Create systemd service definition in /etc/systemd/system/remp-mailer-hermes-worker.service. Alter the ExecStart line to reflect the path to your installation.

Now enable and start the service:

Mail sending (Mail worker)

This configures handler responsible for actual sending of emails via a configured mailer.

Create systemd service definition in /etc/systemd/system/remp-mailer-mail-worker.service. Alter the ExecStart line to reflect the path to your installation.

Now enable and start the service:

Scheduled events

Mail job preprocessing

Once you trigger the mail job to be sent, there needs to be some preprocessing to be done before the emails are sent.

Mailer acquires list of user IDs belonging to the target segment and their email addresses. It also removes all the users that might not get the email (they might be unsubscribed) and in case of an AB testing assigns specific mail templates to specific emails so the sending worker doesn't need to do any heavy-lifting.

Add following block to your crontab to execute the processing (alter the path based on your installation):

Mail stats processing

If the default mailer supports statistics (e.g. Mailgun) and the stats are being received, you can enable stats aggregation, so they're displayed right in the job detail.

Authentication

The default implementation authenticates via REMP SSO.

However, the easiest way to start is to use SimpleAuthenticator with predefined list of emails and passwords. It requires no external authentication services.

Simple authenticator

To install SimpleAuthenticator, please add the following to your config.local.neon (services section):

Call addUser() for every valid email-password combination you want to add.

Custom authentication

It is possible for Mailer to use external authentication without the need of having SSO installed.

To replace REMP SSO with your custom authentication, you need to:

Last step is to add these new implementations to config.local.neon. See following section to read an example based on integration with REMP CRM and replace the classes with your own implementation.

REMP CRM integration

See the Remp\MailerModule\Models\Auth\Authenticator implementation and Remp\MailerModule\Models\Auth\RemoteBearerTokenRepository implementation to check how you can initialize your class the dependencies, structure the request and process the result

The following snippet needs to be added to your config.local.neon to enable integration with CRM. Classes from the snippet are using REMP CRM to authenticate users and API keys.

You can see that you override here two services with your own implementation. The third service uses default Nette implementation and overrides custom REMP SSO implementation defined in config.neon.

From now on the authentication is not done by redirecting user to SSO but by using default sign in screen available at http://mailer.remp.press/sign/in.

Error tracking

Mailer comes with extension supporting tracking errors to Sentry. You can enable the tracking by setting following snippet to your app/config/config.local.neon:

Please be aware, that the tracking works only if you have debug mode disabled. By default, debug mode is enabled only when ENV is set to local.

Healthcheck

Route http://mailer.remp.press/health provides health check for database, Redis, storage and logging.

Returns:

Database tables migration

Because of need of changing primary keys (int -> bigint), in tables that contain lots of data (or have risk of overflowing primary key if its int), we had to create migration process. Since some tables are very exposed and cannot be locked for more than a couple of seconds, we decided to create new tables, migrate the data manually and keep the old and new table in sync while migrating.

This migration process is necessary only for installations after specific version for specific table, and is two steps process.

Mail logs migration (version < 1.1.0)

Consists of mail_logs and mail_log_conversions table migration. Also contains adding user_id column to mail_logs table.

Steps:

  1. running phinx migration CreateNewMailLogsAndMailConversionsTable - which creates new tables mail_logs_v2 and mail_log_conversions_v2 (in case there is no data in tables, migration just changes type of primary key and next steps are not needed)
  2. running command mail:migrate-mail-logs-and-conversions which copies data from old tables to new (e.g. mail_logs to mail_logs_v2) - command will after successful migration atomically rename tables (e.g. mail_logs -> mail_logs_old and mail_logs_v2 -> mail_logs) so when the migration ends only new tables are used

It's recommended to run (in order):

  1. mail:bigint_migration_cleanup mail_log_conversions
  2. mail:bigint_migration_cleanup mail_logs

commands, at least 2 weeks (to preserve backup data, if some issue emerges) after successful migration to drop left-over tables.

User subscription migration (version < 1.2.0)

Consists of mail_user_subscriptions and mail_user_subscription_variants table migration.

Steps:

  1. running phinx migration CreateNewMailUserSubscriptionsAndMailUserSubscriptionVariantsTables - which creates new tables mail_user_subscriptions_v2 and mail_user_subscription_variants_v2 (in case there is no data in tables, migration just changes type of primary key and next steps are not needed)
  2. running command mail:migrate-user-subscriptions-and-variants which copies data from old tables to new (e.g. mail_user_subscriptions to mail_user_subscriptions_v2) - command will after successful migration atomically rename tables (e.g. mail_user_subscriptions -> mail_user_subscriptions_old and mail_user_subscriptions_v2 -> mail_user_subscriptions) so when the migration ends only new tables are used

It's recommended to run (in order):

  1. mail:bigint_migration_cleanup mail_user_subscription_variants
  2. mail:bigint_migration_cleanup mail_user_subscriptions

commands, at least 2 weeks (to preserve backup data, if some issue emerges) after successful migration to drop left-over tables.

Autologin tokens migration (version < 1.3.0)

Consists of autologin_tokens table migration.

Steps:

  1. running phinx migration CreateNewAutologinTokensTable - which creates new table autologin_tokens_v2 (in case there is no data in table, migration just changes type of primary key and next steps are not needed)
  2. running command mail:migrate-autologin-tokens which copies data from old tables to new (autologin_tokens to autologin_tokens_v2) - command will after successful migration atomically rename tables (autologin_tokens -> autologin_tokens_old and autologin_tokens_v2 -> autologin_tokens) so when the migration ends only new tables are used

It's recommended to run mail:bigint_migration_cleanup autologin_tokens command, at least 2 weeks (to preserve backup data, if some issue emerges) after successful migration to drop left-over tables.

API Documentation

All examples use http://mailer.remp.press as a base domain. Please change the host to the one you use before executing the examples.

All examples use XXX as a default value for authorization token, please replace it with the real token API token which can be acquired in the REMP SSO.

API responses can contain following HTTP codes:

Value Description
200 OK Successful response, default value
400 Bad Request Invalid request (missing required parameters)
403 Forbidden The authorization failed (provided token was not valid)
404 Not found Referenced resource wasn't found

If possible, the response includes application/json encoded payload with a message explaining the error further.


POST /api/v1/users/user-registered

When user is registered, Mailer should be notified so it can start tracking newsletter subscription for this new email address. This new email address will be automatically subscribed to any newsletter that has enabled auto subscribe option.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Params:
Name Value Required Description
email String yes Email address of user.
user_id String/Integer _(validated by FILTER_VALIDATEINT) yes ID of user.
Example:

Response:


POST /api/v1/users/bulk-user-registered

Similar to previous api users/user-registerd. Subscribes multiple provided users.

When user is registered, Mailer should be notified so it can start tracking newsletter subscription for this new email address. This new email address will be automatically subscribed to any newsletter that has enabled auto subscribe option.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Body:
Properties of one user
Name Value Required Description
email String yes Email address of user.
user_id String/Integer _(validated by FILTER_VALIDATEINT) yes ID of user.
Example:

Response:

Example with errors:

Response:


POST /api/v1/users/is-unsubscribed

API call that checks if user is unsubscribed from given newsletter list.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Body:
Example:

Response:


POST /api/v1/users/is-subscribed

API call that checks if user is subscribed from given newsletter list (and optionally its variant).

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Body:
Example:

Response:


POST /api/v1/users/user-preferences

API call to get subscribed newsletter lists and their variants.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Body:
Example:

Response:


POST /api/v1/users/subscribe

API call subscribes email address to the given newsletter. Newsletter has to be already created. Currently, there's no API endpoint for that and the newsletter needs to be created manually. Please visit /list/new to create a newsletter via web admin.

If newsletter list has variants, following behavior applies:

Please be aware, that the described variant subscription behavior can be suppressed by sending force_no_variant_subscription=true. If sent, no variant is subscribed, even if it was provided explicitly.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Body:
Example:

Response:


POST /api/v1/users/un-subscribe

API call unsubscribes email address from the given newsletter. Optionally, one can specify newsletter variant to unsubscribe. By default, if list type has multiple variants and user unsubscribes from all of them, system also unsubscribes from the main newsletter list. To change the default behaviour, one can specify keep_list_subscription parameter - if true, this endpoint call retains main list subscription even if no variant is subscribed.

Endpoint accepts an optional array of RTM (REMP's UTM) parameters. Every link in email send by Mailer contain RTM parameters referencing to the specific instance of sent email. If user unsubscribes via specific email, your frontend will also receive special RTM parameters, that can be passed to this API call. For instance link to unsubscribe from our daily newsletter might look like this:

The newsletter_daily stands for newsletter list code. RTM parameters reference specific email and specific batch which generated this email. If you won't provide/pass these RTM parameters, statistics related to unsubscribe rate of emails won't be available.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Body:
Example:

Response:


POST /api/v1/users/bulk-subscribe

Bulk subscribe allows subscribing and unsubscribing multiple users in one batch. For details about subscribe / unsubscribe see individual calls above.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Body:
Properties of one users element
Name Value Required Description
email String yes Email address of user.
user_id String/Integer _(validated by FILTER_VALIDATEINT) yes ID of user.
subscribe Boolean yes Flag to indicate if user should subscribed or un-subscribed.
list_id Integer yes _(use list_id or listcode) ID of mail list.
list_code String yes _(use list_id or listcode) Code of mail list.
variant_id Integer no Optional ID of variant.
rtm_params Object no Optional RTM parameters for pairing which email caused the user to unsubscribe.
utm_params Object no (Deprecated) UTM parameters are deprecated, but if no RTM paramters are found, system will try to use these.
send_accompanying_emails Boolean no Whether or not to send welcome or goodbye email to the user whom subscription is being changed. Defaults to TRUE.
Example:

Response:

Example with errors:

Error Response:


GET /api/v1/users/check-token

Verifies validity of autologin token provided within email.

Each email can contain {{ autologin }} block within the template. When used within an URL (such as https://predplatne.dennikn.sk{{ autologin }}), special token is generated and appended to the URL.

Token is appended as a query parameter token, for example:

Your frontend application can read this token on a visit and verify against this API whether it's still valid or not. If it's valid, you can automatically log user in based on the ID/email the endpoint provides.

Body:
Example:

Response:


POST /api/v1/users/email-changed

If your system allows users to change their email addrses, Mailer needs to be notified about the address change as the subscription information is being stored on user_id/email level.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Params:
Name Value Required Description
original_email String yes Original email address of user.
new_email String yes New email address of user.
Example:

Response:


POST /api/v1/users/logs-count-per-status

Returns number of emails matching the status based on given timeframe. Count is returned separately for each selected status.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Body:
Example:

Response:


POST /api/v1/users/logs

Returns mail logs based on given criteria.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Body:
Filter can also be in a format:
Example:

Response:


POST /api/v1/users/delete

Removes all user data for given email

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Body:
Example:

Response:


GET /api/v1/mailers/mail-types

Lists all available newsletter lists (mail types). Code of the newsletter is required when creating new email template via API.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Params:
Name Value Required Description
code String no Filter only newsletter (mail type) with specific code.
public_listing Boolean no Flag whether only newsletters (mail types) hat should/shouldn't be available to be listed publicly should be returned.
Example:

Response:


GET /api/v2/mailers/mail-types

Lists all available newsletter lists (mail types). Code of the newsletter is required when creating new email template via API.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Params:
Name Value Required Description
code String[] no Filter only newsletters (mail types) with specific code. Multiple codes can be requested.
mail_type_category_code String no Filter only newsletters (mail types) of specific category. Multiple categories can be requested.
public_listing Boolean no Flag whether only newsletters (mail types) hat should/shouldn't be available to be listed publicly should be returned.
Example:

Response:


GET /api/v3/mailers/mail-types

Lists all available newsletter lists (mail types). Code of the newsletter is required when creating new email template via API. Compared to v2, v3 returns all important variant attributes (id, code, sorting, title).

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Params:
Name Value Required Description
code String[] no Filter only newsletters (mail types) with specific code. Multiple codes can be requested.
mail_type_category_code String no Filter only newsletters (mail types) of specific category. Multiple categories can be requested.
public_listing Boolean no Flag whether only newsletters (mail types) hat should/shouldn't be available to be listed publicly should be returned.
Example:

Response:


GET /api/v1/mailers/mail-type-categories

Get available categories of newsletters.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Example:

Response:


POST /api/v1/mailers/mail-type-upsert

Creates or updates mail type (newsletter list). Endpoint complements creation of newsletter list via web interface.

If existing id/code is provided, API handler updates existing record, otherwise a record is created. Field id has higher precedence in finding the existing record.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Body:
Example:

Response:


GET /api/v1/mailers/mail-templates

Get available mail templates. Possible filtering by mail_type_code to get only emails belonging to specified newsletter lists.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Example:

Response:


GET /api/v1/mailers/templates

Gets list of available email templates.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Params:
Name Value Required Description
codes String[] no If provided, list only email templates for given mail_template codes.
mail_type_codes String[] no If provided, list only email templates for given mail_type codes.
with_mail_types Boolean no If true, each returned email template contains additional parameters about assigned mail_type.
page Integer no Pagination. Select which page to return. Required if with limit parameter is used.
limit Integer no Pagination. Limit number of records returned for one page. Required if page parameter is used.
Example:

Response:


POST /api/v1/mailers/templates

Creates new email template. Endpoint complements creation of template via web interface.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Params:
Name Value Required Description
name String yes User-friendly name of the email. It's displayed only in the administration parts of the system.
code String yes Computer-friendly name of the email (slug). Primarily being used when referencing single email that's being sent manually.
description String yes Internal description, so you know even after a year what the purpose of email was.
mail_layout_id String yes ID of layout to be used for email. If you're providing full HTML/text content, we recommend creating "empty" layout only with content within body.
mail_type_code String yes Code of newsletter list the email should belong to. Before the email is sent to specific end-user, Mailer checks whether the user is subscribed to this newsletter or not. If he/she is not, the email will not be sent.
from String yes Who should be used as a sender of email.
subject String yes Email subject.
template_text String yes Text version used as a fallback by email clients.
template_html String yes HTML (primary) version of email that people will see. HTML version is being previewed in the form for creation of new email.
click_tracking Boolean no Boolean flag to determine whether click tracking should be attempted on created template. If not provided, system's default settings is used.
extras String no JSON-encoded arbitrary metadata used internally for email personalization and just-in-time (per-user when sending) email content injection
Example:

Response:


GET /api/v1/mailers/generator-templates

Endpoint generates HTML and text content of email based on the selected generator template and provided arbitrary parameters based on the used generator. It complements generation of HTML/text content via web interface.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Example:

Response:


POST /api/v1/mailers/generate-mail

Endpoint generates HTML and text content of email based on the selected generator template and provided arbitrary parameters based on the used generator. It complements generation of HTML/text content via web interface.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Params:
Name Value Required Description
source_template_id String yes if CODE not provided ID of generator template to be used.
source_template_code String yes if ID not provided CODE of generator template to be used.

Any other parameters are specific to each generator and require knowledge of the generator implementation. See apiParams() method of the generator for the list of available/required parameters.

Example:

The command uses generator template linked to the UrlParserGenerator.

Response:


GET /api/v1/mailers/render-template

Gets rendered email content by code. Both HTML and text variants are provided.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Params:
Name Value Required Description
code String yes Code of template to render.
Example:

Response:


GET /api/v1/segments/list

Lists all available segments that can be used in jobs.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Example:

Response:


POST /api/v1/mailers/jobs

Creates a new sending job with single batch configured to be sent immediately and to randomized list of emails. The job is automatically in ready state indicating to processing daemon that it should be sent right away.

Endpoint complements manual job creation via web interface.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Params:
Name Value Required Description
segment_code String yes Code of the segment to be used.
segment_provider String yes Segment provider owning the segment.
template_id String yes ID of email.
context String no Context to be used.
mail_type_variant_code String no Specify mail type variant code to be used.
start_at String no RFC 3339 date format; Specify the start of sending.
Example:

Response:


POST /api/v1/mailers/preprocess-generator-parameters

Parses arbitrary input - usually data as they're provided by 3rd party (e.g. Wordpress) and returns generator parameters usable to submit to generator (either via API or web).

See preprocessParameters() bullet of Implementing Generator section for integration example.

Headers:
Name Value Required Description
Authorization Bearer String yes API token.
Body:
Example:

Following example uses NewsfilterGenerator which expects values from Wordpress post on the input. Preprocessing is expecting JSON-encoded instance of Wordpress post. We've included only necessary parameters to show the transformation that generator makes.

Response:

{
    "status": "ok",
    "data": {
        "editor": "Admin Admin",
        "title": "Example article",
        "url": "https://www.example.com/article",
        "summary": "Lorem ipsum...",
        "newsfilter_html": " -- Wordpress text content --",
        "source_template_id": 20
    },
    "generator_post_url": "http://mailer.remp.press/mail-generator/"
}

Transformed data can be then used as parameters of /api/v1/mailers/generate-mail endpoint.

As of the writing of this description, not all generators are required to provide preprocessing of parameters. It's a responsibility of the caller to know whether the source template uses generator that can preprocess parameters. If the preprocess is called for a generator not supporting it, HTTP 400 Bad Request is returned with error message.


POST /api/v1/mailers/mailgun

Webhook endpoint for legacy Mailgun event reporting. We advise using v2 of this endpoint and new implementation of webhooks on Mailgun.

You can configure Mailgun webhooks in the Mailgun's control panel. For more information about Mailgun webhooks, please check the documentation, quick guide or guide to webhooks.

Webhook configuration should be enough to enable the tracking in Mailer. Following example is displayed primarily for testing purposes and completeness.

Params:
Name Value Required Description
mail_sender_id String yes Back-reference to specific email Mailer sent.
timestamp String yes Timestamp when event occurred.
token String yes Verification field.
signature String yes Verification field.
recipient String yes Email address of recipient.
event String yes Type of email that occurred.
Example:

The example serves only for debugging purposes, you shouldn't really need to call it yourself.

curl -X POST \
  http://mailer.remp.press/api/v1/mailers/mailgun \
  -H 'Authorization: Bearer XXX' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d 'mail_sender_id=foo&timestamp=1529006854&token=a8ce0edb2dd8301dee6c2405235584e45aa91d1e9f979f3de0&signature=d2271d12299f6592d9d44cd9d250f0704e4674c30d79d07c47a66f95ce71cf55&recipient=admin%40example.com&event=opened'

Response:

{
    "status": "ok",
}

The event itself is just validated and put to the asynchronous queue to be processed later.


POST /api/v2/mailers/mailgun

Webhook endpoint for new Mailgun event reporting. Comparing to v1 the payload provided by Mailgun is more descriptive and is sent as a JSON body instead of HTTP form parameters.

You can configure Mailgun webhooks in the Mailgun's control panel. For more information about Mailgun webhooks, please check the documentation , quick guide or guide to webhooks.

Webhook configuration should be enough to enable the tracking in Mailer. Following example is displayed primarily for testing purposes and completeness.

Body:
{
  "signature": {
    "timestamp": "1529006854",
    "token": "a8ce0edb2dd8301dee6c2405235584e45aa91d1e9f979f3de0",
    "signature": "d2271d12299f6592d9d44cd9d250f0704e4674c30d79d07c47a66f95ce71cf55"
  },
  "event-data": {
    "event": "opened",
    "timestamp": 1529006854.329574,
    "id": "DACSsAdVSeGpLid7TN03WA",
    // ...
  }
}
Example:

The example serves only for debugging purposes, you shouldn't really need to call it yourself. More verbose of example can be found in Mailgun's blogpost introducing new version of webhooks.

curl -X POST \
  http://mailer.remp.press/api/v2/mailers/mailgun \
  -H 'Authorization: Bearer XXX' \
  -H 'Content-Type: application/json' \
  -d '{
  "signature": {
    "timestamp": "1529006854",
    "token": "a8ce0edb2dd8301dee6c2405235584e45aa91d1e9f979f3de0",
    "signature": "d2271d12299f6592d9d44cd9d250f0704e4674c30d79d07c47a66f95ce71cf55"
  },
  "event-data": {
    "event": "opened",
    "timestamp": 1529006854.329574,
    "id": "DACSsAdVSeGpLid7TN03WA"
  }
}'

Response:

{
    "status": "ok",
}

The event itself is just validated and put to the asynchronous queue to be processed later.


POST /api/v1/mailers/send-email

Endpoint for sending single email without creating a job. It should be primarily used for system (event based) emails and testing emails.

Body:
{
  "mail_template_code": "welcome_email_with_password",
  "email": "[email protected]",
  "params": { // optional: key-value string pairs of parameters to be used mail_template variables
    "email": "[email protected]",
    "password": "secret"
  },
  "context": "user.welcome.123", // optional: if email with the same context and mail_template_code was already sent, Mailer will not send the email again
  "attachments": [ // optional
    {
      "file": "/path/to/file", // used to determine name of attachment and possibly content of attachment
      "content": "-- base64 encoded content of attachment --" // if content is not provided, Mailer attempts to open file based on provided path in "file" property
    }
  ],
  "schedule_at": "2019-09-23T08:50:03+00:00", // optional: RFC3339-formatted date when email should be sent; if not provided, email is scheduled to be sent immediately
  "locale": "en" // optional: specify language version of email
}
Example:
curl -X POST \
  http://mailer.remp.press/api/v1/mailers/send-email \
  -H 'Authorization: Bearer XXX' \
  -H 'Content-Type: application/json' \
  -d '{
    "mail_template_code": "welcome_email_with_password",
    "email": "[email protected]"
}

Response:

{
    "status": "ok",
    "message": "Email was scheduled to be sent."
}

Actual sending is being processed asynchronously by background workers and might be delayed based on available system resources and size of the background processing queue.


POST /api/v1/mailers/mail-type-variants

Creates new mail type variant.

Body:
{
  "mail_type_code": "type-25",
  "title": "Variant 1",
  "code": "variant-1",
  "sorting": 100
}
Example:
curl -X POST \
  http://mailer.remp.press/api/v1/mailers/mail-type-variants \
  -H 'Authorization: Bearer XXX' \
  -H 'Content-Type: application/json' \
  -d '{
    "mail_type_code": "type-25",
    "title": "Variant 1",
    "code": "variant-1",
    "sorting": 100
}

Response:

{
    "status": "ok",
    "id": 24066 // Integer; ID of created mail type variant
}

All versions of mailer-module with dependencies

PHP Build Version
Package Version
Requires php Version ^8.1
ext-intl Version *
ext-json Version *
ext-pdo Version *
embed/embed Version ^4.3
guzzlehttp/guzzle Version ^7.0
halaxa/json-machine Version ^1.1
justinrainbow/json-schema Version ^5.2
latte/latte Version ^3.0
league/event Version ^3.0
mailgun/mailgun-php Version ^4.0
monolog/monolog Version ^3.0
nette/application Version ^3.2
nette/bootstrap Version ^3.0
nette/caching Version ^3.0
nette/database Version ^3.0
nette/di Version ^3.0
nette/forms Version ^3.0
nette/http Version ^3.0
nette/mail Version ^4.0
nette/robot-loader Version ^4.0
nette/security Version ^3.1 <3.2
nette/utils Version ^4.0
contributte/webpack Version ^2.2
predis/predis Version ^1.1
remp/remp-commons Version @dev|^0.32
robmorgan/phinx Version ^0.15
rootpd/nette-sentry Version ^2.0
symfony/console Version ^6.4
symfony/http-client Version ^6.4
tomaj/hermes Version ^4.0
tomaj/nette-api Version ^2.1
tomaj/nette-bootstrap-form Version ^2.1
tracy/tracy Version ^2.6
twig/twig Version ^3.1
twig/intl-extra Version ^3.3
vlucas/phpdotenv Version ^5.2
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package remp/mailer-module contains the following files

Loading the files please wait ....