Trigger Mailings

Trigger mailings are mailings that are triggered by external events and can be sent directly via API. Typical examples are password resets, booking confirmations, or welcome emails.

Basics

Trigger mailings must be created and activated in advance by editors in mail2many. They are identified by a unique TriggerType.

Important:

• Sender name and subject are defined by the editor.
• Delivery is done via API, not manually in the account.
• If the mailing is changed in mail2many, the API call does not need to be adjusted — the TriggerType remains the same.
• TriggerTypes can be used across multiple accounts, allowing different accounts of one customer to use the same TriggerType.
• Trigger types can be retrieved via: GET /triggerTypes.
• Multilingual behavior is controlled with the language parameter.

Placeholders

Trigger mailings are regular mailings, but they typically contain at least one article with a trigger template. This template contains fillable placeholders for personalized content:

Examples:

• {resetLink} – Password reset link
• {bookingId} – Booking ID
• {productName} – Product or service name

note

Available placeholders are defined per template. There is currently no API to list placeholders — ask the trigger mailing developer for details.

Example: Single Trigger with individual placeholders

Trigger Template: "Password Reset"
  Hello {firstname},
  Click here: {resetLink}
  Usually valid for: {validHours} hours

API call with 3 subscribers:

  Subscriber 1: max@example.com
    ├─ {firstname} = "Max"
    ├─ {resetLink} = "https://example.com/reset/abc123"
    └─ {validHours} = "24"
    └→ Email: "Hello Max, Click here: https://example.com/reset/abc123..."

  Subscriber 2: lisa@example.com
    ├─ {firstname} = "Lisa"
    ├─ {resetLink} = "https://example.com/reset/def456"
    └─ {validHours} = "24"
    └→ Email: "Hello Lisa, Click here: https://example.com/reset/def456..."

  Subscriber 3: john@example.com
    ├─ {firstname} = "John"
    ├─ {resetLink} = "https://example.com/reset/ghi789"
    └─ {validHours} = "24"
    └→ Email: "Hello John, Click here: https://example.com/reset/ghi789..."

Two variants

When creating a trigger mailing, the editor must choose between two variants. This decision also determines which APIs are available for sending.

Single Trigger

Use case: One or a few subscribers in real time with aggregated statistics

For single trigger mailings, you only call one API flow. The trigger mailing is sent immediately when the API is called for a subscriber.

Characteristics:

• Immediate delivery
• Aggregated statistics (all sends combined)
• Two endpoints available:
  • POST /mailings/singleTrigger – one subscriber per request
  • POST /mailings/singleTrigger/batch – up to 100 subscribers in one request
• Placeholders can be filled differently per subscriber (useful for booking confirmations with individual data)
• Sender name and subject can be overridden for the entire request or per subscriber

Campaign Trigger

Use case: Large subscriber groups with delayed delivery and per-campaign statistics

For campaign trigger mailings, you first create a copy of the trigger mailing, then transfer subscribers into that copy, and finally schedule delivery of the copy. This is suitable, for example, for newsletters to customers without a purchase in the last 6 months.

Characteristics:

• Background delivery (asynchronous)
• Status can be retrieved via: GET /mailings/trigger/{id}
• Statistics can be analyzed separately per campaign (through the copy)
• Multi-step flow:
  1. POST /mailings/trigger – create copy
  2. POST /mailings/trigger/{id}/receivers – transfer subscribers
  3. POST /mailings/trigger/{id}/schedule – schedule delivery
• Sender name and subject can be overridden globally when creating the copy or optionally per subscriber

Comparison

Criterion	Single Trigger	Campaign Trigger
Subscribers	One or a few	Larger subscriber volumes
Delivery	Immediate	In background
Statistics	Aggregated	Per campaign
Endpoints	2 (single + batch)	3 (create, receivers, schedule)
Placeholders	Per subscriber	Per subscriber
Typical use cases	Password reset, confirmation	Targeted newsletters, campaigns

API integration

Detailed request and response examples for both variants are available in the Endpoint Documentation.