Ometria's transactional API is used to trigger instant email messages to recipients for transactional purposes, e.g. order confirmation emails. The API ignores suppression lists for transactional sends, so your contacts will receive transactional emails regardless of their opt-in status.
Ometria's rate limit for sending transactional emails is 10 requests per second.
A typical implementation would involve a queue based system making calls to the Ometria API.
You can set up a different sending domain or subdomain to provide differentiation between marketing and transactional emails. E.g.
There are two ways to handle transactional email templates:
- Hosted in Ometria
- Passing the HTML template in the API call
This method is great if you'd like Ometria to code your templates for you, and all the template assets such as images can be hosted by the Ometria asset manager.
This means it's potentially easier for marketers to make creative changes to templates without help from developers.
Speak to your Customer Success Manager about pricing.
Once the template is created, you’ll need to pass the template ID and all the fields to merge in the API call.
This option is quicker to implement if you are already generating your own templates, and allows you to manage the merging of data.
You'll need to include the full HTML with all the data merged into it in the API call.
We recommend running your existing transactional email pipeline and the Ometria transactional email API in parallel when testing.
This will allow for a quick switch when you are ready to go live as well as making it easier to rollback if required.
Testing in parallel requires transactional email records to be sent with the
"sandbox”:true flag on the transactional email record.
Updated 10 months ago