Rebuilding the email layer behind inHarmony’s iOS and Android meditation platform using GoHighLevel.
Key takeaways
- Marketing platforms break transactional email structurally, not accidentally shared sender reputation and consent-first suppression put your login flow behind rules built for newsletters.
- Abstract the email provider before migrating anything one interface costs a day and turns a big-bang cutover into a config change with instant rollback.
- GoHighLevel’s Do Not Disturb flag blocks transactional email too an unsubscribe silences password resets, with no native bypass.
- Separate the sending reputation or you have changed nothing a dedicated subdomain with SPF, DKIM, and DMARC keeps campaigns from damaging OTP delivery.
- The worst failure mode is silent success the API returns 200 and the user gets nothing, so log every send with a correlation ID.
Introduction
A marketing email that lands in spam costs you a click.
A one-time passcode that lands in spam costs you a customer.
That distinction sat at the centre of a recent engagement with inHarmony, a wellness brand that pairs long-form guided meditations with its own line of vibroacoustic hardware. Their iOS and Android app is, at a surface level, a music player. Underneath, it is the access layer to a content library that users have paid for and to hardware sitting in their living room. Tracks run from ten minutes to two hours. Users download them for offline playback. The audio routes through inHarmony’s physical devices.
Which means when a verification email or a password reset fails to arrive, the user is not mildly inconvenienced. They are locked out of a device they spent real money on, holding a phone that will not let them back in.
inHarmony had been running those emails through Klaviyo since 2021 a platform they deliberately chose over SendGrid at the time. By the time they came to us, delivery failures on critical app emails had become frequent enough to generate support tickets. They had identified GoHighLevel as the replacement and needed the app’s email layer moved across without disrupting live users.
Here is how we approached it, and the things we would tell any team attempting the same migration.
Why a marketing platform eventually breaks transactional email
It is worth being precise about the failure mode here, because “Klaviyo has bad deliverability” is neither accurate nor the lesson.
Klaviyo is an excellent marketing automation platform. The problem is structural: it is built around the concept of a marketing profile with a consent status, and transactional email does not fit that model cleanly.
Four specifics shaped inHarmony’s experience:
- Transactional status is not a toggle you control. In Klaviyo, marking a flow as transactional requires review and approval it is not something a developer flips on at 2am when OTPs stop landing.
- Even approved transactional flows skip certain profiles. Klaviyo documents that suppressed profiles still receive transactional messages except where the suppression came from a hard bounce, seven consecutive soft bounces, or a prior spam complaint. Those profiles are silently skipped. From the app’s perspective the API call succeeded. From the user’s perspective nothing arrived.
- Marketing and app traffic share a sender reputation. inHarmony was running promotional campaigns and app OTPs through the same platform and, in practice, the same reputation. A campaign that drew complaints degraded the inbox placement of password resets sent hours later.
- Consent status leaks into operational messaging. A user who unsubscribed from the newsletter in 2023 is still entitled to reset their password in 2026. Reconciling that inside a consent-first data model takes constant vigilance.
None of this is a Klaviyo defect. It is what happens when a marketing tool is asked to carry an authentication workload for five years while the app around it grows.
Takeaway. The moment your app’s authentication emails and your campaign emails share the same sending reputation and suppression logic, you have a single point of failure in your login flow on the wrong side of it.
Scope: six templates on a critical path
The app group inside inHarmony’s Klaviyo account held six templates. A small surface area but every one sits on a path where failure means a locked-out user or a broken support promise.
| TEMPLATE | TRIGGER SOURCE | FAILURE IMPACT |
| Single-use coupon | Admin panel | Promised discount never arrives; support ticket |
| Sign-up verification ▪ auth | iOS / Android | New user cannot activate their account |
| Forgot password ▪ auth | iOS / Android | Existing user locked out of paid content and device |
| Welcome email (admin-created user) | Admin panel | Onboarded user never receives credentials |
| Admin-triggered password resend ▪ auth | Admin panel | Support cannot resolve an access issue |
| OTP resend ▪ auth | iOS / Android | Auth loop the user retries, generating more failures |
Four of the six are authentication. One is a fulfilment promise. This was not a marketing migration; it was an availability migration that happened to involve email.
The architecture we landed on
1. A provider abstraction layer came first
Before touching a single template, we introduced an email provider interface in the backend. The application code stopped knowing that Klaviyo existed and started calling a generic dispatcher.
// emailService/types.ts
export type TransactionalEmail =
| { type: 'VERIFY_SIGNUP'; to: string; data: VerifyData }
| { type: 'FORGOT_PASSWORD'; to: string; data: ResetData }
| { type: 'OTP_RESEND'; to: string; data: OtpData }
| { type: 'SINGLE_USE_COUPON'; to: string; data: CouponData }
| { type: 'ADMIN_WELCOME'; to: string; data: SetPasswordData }
| { type: 'ADMIN_PASSWORD_RESEND'; to: string; data: SetPasswordData };
export interface EmailProvider {
send(
email: TransactionalEmail,
ctx: { requestId: string },
): Promise<{ providerMessageId: string }>;
}With KlaviyoProvider and GoHighLevelProvider both implementing that interface, provider selection became a runtime config value rather than a deployment.
That single decision is what made everything downstream possible shadow sending, percentage rollout, and instant rollback.
If you take one thing from this article: never call an ESP SDK directly from your business logic. The Node.js development costs about a day and buys you the entire migration strategy.
CONFIRM Replace the code sample with the actual language and framework used on inHarmony’s backend. Node/TypeScript is assumed here.
2. Exporting and translating the templates
Klaviyo templates are HTML with Klaviyo’s own Django-style tag syntax; GoHighLevel uses its own merge-field conventions. There is no automated bridge between them, so the work was a deliberate translation pass.
| KLAVIYO | GOHIGHLEVEL |
| {{ event.coupon_code }} | {{inboundWebhookRequest.coupon_code}} |
| {{ person.first_name }} | {{inboundWebhookRequest.first_name}} |
| {% if event.expires_on %}…{% endif %} | Handled as a workflow branch, not in-template |
| Klaviyo block-builder layout | Raw HTML in a custom code block |
Two practical notes:
- Klaviyo’s builder output is heavily inlined and wrapped in MSO conditional comments. Pasting it into a WYSIWYG editor will mangle it. We imported the raw HTML into GoHighLevel’s code block instead, keeping the markup intact and preserving Outlook rendering.
- GoHighLevel does not support arrays in custom values from a webhook payload. Anything Klaviyo handled as a loop had to be flattened into discrete, pre-formatted fields by the backend before dispatch.
3. One workflow per template, triggered by inbound webhook
Each of the six templates became its own GoHighLevel workflow automation using the Inbound Webhook trigger API integration services a premium trigger that generates a unique URL and fires on an incoming POST.
POST /hooks/{location}/webhook-trigger/{unique-id}
Host: services.leadconnectorhq.com
Content-Type: application/json
{
"email": "[email protected]",
"first_name": "Alex",
"otp": "482913",
"expires_in_mins": 10,
"request_id": "a4f1e0c2-...",
"template": "OTP_RESEND"
}
Three constraints worth knowing before you design your payloads:
- An email or phone number is mandatory in every payload. GoHighLevel’s model is contact-first the webhook performs a find-or-create against the CRM before the workflow proceeds.
- The mapping reference must be re-saved whenever your payload shape changes. Add a field to the JSON and forget this step, and the merge field silently resolves to empty. We caught two of these in staging.
- The webhook URL is the only credential. There is no signing secret. Treat it as a secret in your config store, and note that rotating it means deleting the trigger and creating a new one so build the URL as an environment variable, never a hardcoded string.
CONFIRM Verify the exact webhook URL format in use and redact any real location or trigger IDs before this is published.
4. Isolating the sending reputation
This was the fix for the actual root cause, and it is the step teams skip.
We separated app transactional sending from marketing sending a dedicated sub-account and a dedicated sending subdomain, with full SPF, DKIM and DMARC authentication, warmed gradually rather than switched on at full volume.
CONFIRM Confirm whether a separate sub-account or a shared one was used, and the exact sending subdomain (for example notify.iaminharmony.com).
The point is not the specific configuration. It is the principle: a promotional campaign should never be able to damage the inbox placement of a password reset. If those two streams share a domain reputation, you have rebuilt the original problem on a new platform.
The gotcha that nearly bit us: DND blocks transactional email
This deserves its own section, because it is the single most important thing to know before moving app authentication emails to GoHighLevel.
In GoHighLevel, when a contact unsubscribes from an email, the platform defaults to enabling Do Not Disturb across all channels for that contact. Once DND is on, workflow email actions to that contact are blocked and the block does not distinguish between a promotional newsletter and a password reset.
There is no native “this is transactional, bypass DND” flag. It is one of the most-requested items on GoHighLevel’s own public feature board, with agencies describing exactly this failure: a customer unsubscribes from marketing, then makes a purchase, and the invoice email silently fails. The same thread notes that unsubscribed contacts can also land on the underlying Mailgun suppression list, where simply clearing the DND flag in the CRM does not necessarily restore deliverability.
Migrate naively and you do not fix the original problem you reproduce it with different branding.
How we handled it
- Kept app transactional sending isolated from any list that carries a standard marketing unsubscribe, so the DND state is never set by a campaign in the first place.
- Made the unsubscribe experience on marketing sends explicit that it governs marketing communication only, with account and security emails handled separately.
- Added a pre-send DND check with alerting, so a blocked authentication send raises an internal alarm rather than disappearing. A user who cannot log in should generate a page for us, not a support ticket for them.
- Built a documented remediation path for support to restore eligibility for a specific user including the suppression-list step, not just the CRM flag.
CONFIRM Confirm which of these four mitigations were actually implemented before this is presented to the client.
A security improvement we shipped along the way
Two of the six templates admin-created welcome and admin-triggered password resend involved the admin panel putting credentials in front of a user by email.
Emailing a password, even a temporary one, means that password now lives in an inbox indefinitely, replicated across mail servers and any device that syncs it. Migration was the natural moment to change it.
We moved both flows to single-use, time-limited set-password links identity and access management the email carries a token rather than a credential, the token expires, and it invalidates on first use. The admin experience is unchanged. The security posture is meaningfully different.
Worth saying out loud. A platform migration is one of the few times you have licence to reopen flows nobody has questioned in five years. Use it.
CONFIRM Keep this section only if the tokenised set-password link actually shipped. If it did not, reframe it as a recommendation.
Cutting over without breaking live users
We ran the transition in four stages, all controlled by the abstraction layer from step one.
Stage 1 – Shadow send
Klaviyo remained the live provider. Every triggered email also fired a GoHighLevel dispatch to internal seed inboxes. We compared rendering across the iOS Mail app, Gmail mobile and Outlook, and ran spam-scoring on each of the six templates. Real users were unaffected.
Stage 2 – Percentage rollout
A small share of live traffic routed to GoHighLevel, with delivery, bounce and complaint rates monitored against the Klaviyo baseline.
CONFIRM Add the starting percentage and the ramp schedule actually used.
Stage 3 – Full cutover
One hundred per cent of app transactional traffic on GoHighLevel, with Klaviyo credentials left live and a one-line config rollback available for a defined watch period.
Stage 4 – Decommission
Klaviyo app-group flows were retired only after the watch window closed clean. inHarmony’s marketing team continued on their own stack, untouched throughout.
CONFIRM Confirm whether the marketing stack also moved to GoHighLevel or remained on Klaviyo.
Throughout, every send was logged with a correlation ID, the provider message ID, and the resulting delivery event so “did the user receive it?” became a query rather than a guess. That observability did not exist before the migration, and it is arguably as valuable as the platform change itself.
Results
The three highlighted rows below are placeholders. They should be replaced with measured figures or removed entirely before publication.
| MEASURE | VALUE |
| Delivery rate on app transactional email | XX% → YY% |
| Median time from trigger to inbox (OTP) | XX sec → YY sec |
| Monthly support tickets tagged “didn’t receive email” | XX → YY |
| Templates migrated | 6 |
| User-facing downtime during cutover | Zero |
| Config change required to roll back | One line |
Rows shaded in terracotta require telemetry. The lower three are factual today and stand on their own if the upper three cannot be measured.
What we would tell another team doing this
- Classify your email before you choose a platform. Authentication email and marketing email have different uptime requirements. Decide whether one system can honestly serve both.
- Abstract the provider on day one. It converts a risky big-bang cutover into a config change with a rollback.
- Separate the sending reputation. The same domain for campaigns and password resets means one bad campaign takes down your login flow.
- Read the consent model, not the feature list. Both Klaviyo and GoHighLevel will block sends based on consent state in ways that surprise you. Find those rules before you migrate, not after.
- Instrument everything. The worst failure mode in transactional email is silent success the API returns 200 and the user gets nothing.
- Treat the migration as a chance to fix what is underneath. We shipped a real security improvement because we were already in the code.
Closing
Six templates is not a big migration. But when four of them stand between a user and the meditation library they have paid for routed through hardware sitting in their home the size of the surface has very little to do with the size of the risk.
If your app’s authentication emails are riding on a marketing platform, which is worth a look before it becomes a support queue.
Frequently Asked Questions (FAQs)
Does GoHighLevel support transactional email?
Yes, but not as a distinct message class. GoHighLevel sends email through workflows, and there is no native flag that marks a message as transactional. That means authentication emails are subject to the same consent and suppression rules as marketing sends unless you architect around it.
Does Do Not Disturb block transactional email in GoHighLevel?
Yes. When a contact unsubscribes, GoHighLevel enables Do Not Disturb across all channels by default, and workflow email actions to that contact are blocked. The block does not distinguish a newsletter from a password reset. There is no native bypass, so the practical fix is keeping transactional sending isolated from any list carrying a marketing unsubscribe.
Why not just keep transactional email in Klaviyo?
Klaviyo is built around a marketing profile with a consent status, which does not fit transactional email cleanly. Transactional status requires review and approval rather than being a developer toggle, approved flows still skip profiles suppressed by hard bounces or spam complaints, and marketing campaigns share sender reputation with authentication emails.
How do you migrate transactional email without downtime?
Introduce a provider abstraction layer first so the application calls a generic dispatcher rather than an ESP SDK. Provider selection then becomes a runtime config value, which enables shadow sending to seed inboxes, percentage rollout against a live baseline, full cutover with the old provider still credentialed, and decommission only after a clean watch window.
Should transactional and marketing email use the same sending domain?
No. A promotional campaign that draws complaints will degrade the inbox placement of password resets sent hours later. Use a dedicated sending subdomain for transactional traffic with full SPF, DKIM, and DMARC authentication, warmed gradually rather than switched on at full volume.
How do you convert Klaviyo templates to GoHighLevel?
There is no automated bridge. Klaviyo uses Django-style tags like {{ event.coupon_code }}; GoHighLevel uses {{inboundWebhookRequest.coupon_code}}. Import the raw HTML into a code block rather than a WYSIWYG editor, since Klaviyo’s builder output is heavily inlined and wrapped in MSO conditional comments. Conditional logic moves from the template into workflow branches, and arrays must be flattened into discrete fields before dispatch.
