Transactional Messaging
Transactional Messages let you send user-level messages through backend / API.
They are usually immediate, context-specific, and triggered by a user action or a system event.
Use them for messages such as:
order confirmation
shipping update
appointment reminder
password reset
Path: Messages > Transactional > Create New Transactional Message
Quick steps
Create the transactional template in the panel.
Set a Message Key to identify it in API calls.
Add Message Parameters for personalization (profile attributes).
Decide if the API can override message settings.
Configure limits and time restrictions if needed.
Use Sample Request to test before production use.
How Transactional Messaging works
Transactional Messages follow the standard message flow, with one extra step: API & Config.
Use this extra step to define how your backend will call the message and which parts can be controlled dynamically.
This model is useful when the trigger comes from your own backend instead of a panel-side event rule.
Standard message steps
Transactional Messages still use the standard campaign steps:
Setup — define the message name and base settings.
What — create the message content.
Who — define the recipient scope or targeting logic.
Go — review the configuration before production use.
The extra step for this message type is API & Config.
This is the only part that is specific to Transactional Messages.
There is no separate custom flow instead of Setup and What.
Transactional Messages use the standard message steps plus API & Config.
API & Config
This step defines how your backend sends the message.
It also defines what can be customized in each API call.
Message Key
A unique identifier for this transactional message. Use it to reference the message in API calls and reporting.
Choose a stable and descriptive key.
This makes backend integration, debugging, and reporting easier.
Message Parameters
Parameters are values injected into the message content.
They usually map to profile attributes or payload fields.
Examples:
user name
order number
membership tier
Use parameters when the message content must change per user or per request.
Allow API to override any of message settings
If enabled, the API caller can override settings at send time.
This includes content and delivery-related settings.
Enable this when the backend must control message details dynamically.
Disable it when the panel template must stay fixed.
Sample Request
Use Sample Request to test the message with a real API call. This helps verify payload and personalization before production.
Sample Response
Sample Response shows whether the request succeeded. Use it to debug errors and validate delivery.
Limits and time restrictions
Use limits to control volume. Use time restrictions to control delivery windows.
This is useful when transactional traffic must stay controlled even though it is API-triggered.
Ignore User Message Limits
Bypass user-level message limits for this transactional message. Use this carefully.
It can be useful for critical messages that must bypass standard caps.
Total Limit
Cap the total number of sends allowed for this transactional message.
Use this when the message should stop after a defined volume.
Limit
Cap how often the same user can receive the message within a selected period.
Use it to prevent repeated sends to the same user.
Push Time Restriction
Restrict sending to specific hours or days.
Use this when delivery should happen only in approved time windows.
Transactional Messages are API-triggered, but delivery rules still apply.
Use limits and time restrictions to avoid unwanted volume or off-hours sending.
Other steps
After API & Config, continue with the standard message steps.
These steps match the regular message flow:
Setup
What
Who
Go
Use those steps to configure the content, audience, and final review of the transactional template.
Think of API & Config as the integration layer.
The remaining steps define the message template itself.
Last updated
Was this helpful?