Transactional Journeys is a journey orchestration tool designed for real-time, operational messaging. It is built to send critical messages triggered by system events or backend actions.
Typical use cases include order confirmations, password reset emails, one-time passwords, delivery notifications, and appointment reminders. These messages are expected by the user and must be delivered immediately and reliably, regardless of the user’s opt-in status.
Transactional Journeys is designed with a strict performance expectation. From the moment a valid API request is received, message processing and delivery are handled with a maximum end-to-end service level agreement (SLA) of 30 seconds.
This article explains the following concepts:
What can you do with Transactional Journeys?
With Transactional Journeys, you can:
Trigger journeys directly through an API.
Send Email and SMS messages within the same journey.
Personalize message content using dynamic attributes sent in the API request.
Allow the same user to enter the same journey multiple times, even concurrently.
Manage transactional messaging flows through a visual canvas.
How does Transactional Journeys work?
Every transactional journey starts with an API request.
The request defines:
The journey that should be triggered.
The user or users who should enter the journey.
The dynamic attributes to inject into the message content.
Once the request is received, the system:
Authenticates the request.
Validates the payload structure.
Applies idempotency checks to prevent duplicate processing.
Queues eligible users into the journey for immediate execution.
All steps in this process are optimized for low latency. Transactional Journeys processes users asynchronously, guaranteeing that journey execution and message dispatch occur within the 30-second SLA under normal operating conditions.
Users enter the journey immediately.
Channel elements execute sequentially.
No waiting, branching, or user batching is applied.
Transactional Journeys guarantees an end-to-end SLA of no more than 30 seconds from request acceptance to message dispatch, excluding external provider failures.
Message delivery behavior
Transactional Journeys does not evaluate user opt-in or opt-out status. Messages are sent regardless of subscription state. Delivery outcomes depend on channel-level provider rules. For example, invalid email addresses, unreachable phone numbers, or provider-side failures may result in delivery issues.
Transactional Journeys does not delay, reschedule, or suppress messages at the journey level.
Journey structure
Transactional journeys use a simplified structure optimized for speed and reliability.
A journey consists of:
One API Trigger starter.
One or more channel elements.
A linear execution flow.
Branching, waiting, and conditional evaluation are unavailable in transactional journeys, as they can introduce latency and unpredictability.
When should you use Transactional Journeys?
Transactional Journeys is suitable when:
Messages must be delivered within seconds after a backend action.
A strict delivery SLA is required.
Message content is informational or operational.
Messages should be delivered to all users, regardless of their subscription status.
It is not designed for promotional campaigns, experimentation, or bulk communication strategies.