KoltrixCampaign Builder or Email API? Where SaaS Lifecycle Mail Should Live
Campaign builders and email APIs solve different halves of lifecycle email. Who should own onboarding, trial and billing mail, and when a hybrid setup works.
On this page(7 sections)
Sooner or later every SaaS team has the same argument. Marketing wants onboarding emails in a visual tool where they can edit copy and build flows without waiting for a deploy. Engineering wants them in code, triggered precisely by product events and reviewed like everything else. Both sides are right about something.
This post compares the two categories, campaign and automation platforms versus API-driven sending from your own code, and how to decide which emails belong where.
The two categories
Campaign and automation platforms
These are tools built around audiences, segments and visual workflows. Mailchimp is the best-known example; there are many others aimed at different budgets and audiences, including tools built specifically for SaaS lifecycle messaging. At the time of writing, the common features include:
- Drag-and-drop email editors and template libraries
- Contact lists and segments, often synced from your app or CRM
- Visual automation builders: "when someone joins this segment, wait two days, send this email"
- Reporting on opens, clicks and conversions
- Signup forms, landing pages and sometimes ads integrations
Their great strength is that a non-engineer can own the whole thing. A growth marketer can write, test and change an onboarding sequence in an afternoon.
API-driven sending from your code
Here, your application decides when to send and calls a transactional email API or SMTP relay to deliver the message. Templates live in your codebase or in the provider's template system. The logic, "this user signed up four days ago and still hasn't connected a data source," lives in your app, usually in a scheduled job or an event handler.
Its strength is precision. Your app knows exactly what every user has and hasn't done, in real time, without syncing data to a third party.
Where each one fits
| Consideration | Campaign platform | API from your code |
|---|---|---|
| Who edits copy | Marketing, no deploy needed | Engineers, or anyone via code review |
| Trigger precision | Depends on how fresh synced data is | Exact, based on live product state |
| Complex conditions | Limited to the builder's options | Anything your code can express |
| Segmentation and broadcasts | Built in | You build it, or don't need it |
| Versioning and review | Tool-dependent | Git history and pull requests |
| Testing | Preview and test sends | Unit tests, staging, previews |
| Data leaving your system | Contact and event data synced to vendor | Only what's in each email |
| Visual reporting | Built in | You build it, or use provider stats |
| Setup cost | Low to start, grows with integrations | Engineering time up front |
Sorting your emails
A practical rule: the closer an email is to the product's state, the more it belongs in code. The closer it is to a broadcast, the more it belongs in a campaign tool.
Usually best in code, via an API:
- Password resets, verification, sign-in links
- Receipts, invoices, failed payment and dunning emails
- Trial ending reminders with exact dates
- Plan limit warnings with real usage numbers
- Behavior-triggered onboarding nudges ("you haven't connected X yet")
- Security alerts and account changes
These depend on precise, current data, and getting them wrong has real consequences: a dunning email after someone already paid, a trial reminder after they upgraded.
Usually best in a campaign platform:
- Newsletters and product announcements to your whole base
- Promotional campaigns and event invitations
- Content-driven nurture sequences for leads who haven't signed up
- Emails where marketing needs to iterate on copy weekly
Genuinely either:
- Time-based onboarding tips ("day three: did you know...")
- Win-back emails
- Usage milestone celebrations
For these, the deciding factor is usually who will maintain them. If marketing owns the copy and wants to change it often, a platform helps. If the trigger logic is subtle, code is safer.
The hybrid setup most teams end up with
Many SaaS companies run both, and that's fine if the boundaries are clear:
- Transactional and state-dependent lifecycle email is sent by the app through an email API, from your main domain or a dedicated subdomain.
- Marketing and broadcast email goes through a campaign platform, often from a separate subdomain so a campaign's complaint rate can't affect password resets.
- One source of truth for preferences. If someone unsubscribes from marketing, the platform knows. If someone's account is deleted, both systems stop.
- No duplicate emails. Each event triggers exactly one email from exactly one system. Write down which system owns which email.
The failure mode of a hybrid setup is drift: the same "welcome" email exists in both systems, or the platform keeps sending trial tips to someone who upgraded because the sync lagged. An email inventory catches this.
Where Koltrix sits
Koltrix is on the API side of this comparison. It provides a transactional email API and SMTP relay, plus a team inbox where replies to those emails land. It doesn't include a campaign builder or newsletter product in its first release, so teams that need visual automation and broadcasts will want a campaign platform alongside it, or instead of it. Our comparison with Mailchimp is explicit about when Mailchimp is the better choice.
Questions to settle before choosing
- Who will write and change lifecycle emails over the next year?
- How fresh does the data behind each email need to be?
- Are you comfortable syncing user and event data to a third party?
- Do you need broadcasts and newsletters now, or only triggered email?
- Who will notice when a lifecycle email goes wrong, and how?
Bottom line
Campaign platforms are excellent for broadcasts and for emails a marketer owns and iterates on. Email APIs called from your code are better for anything that depends on precise account state, especially billing, trial and behavior-triggered messages. Most growing SaaS teams end up using both. The important part is drawing a clear line between them, keeping one source of truth for preferences, and making sure no email is sent twice.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
