IxDF Developer Docs

Appearance

Spec: MailerLite Accounts ​

Meta: this document is created by developers for developers and for LLMs, so anyone can feed this doc to LLM and have a perfect context to get answers to almost any questions related to the MailerLite migration 2026.

_

High-level overview ​

We have IxDF Weekly Newsletter ContactList on IxDF-web app that is sync with MailerLite account (at some point we added these around 300k subscribers to MailerLite using API).

We send to subscribers from that list/group 2 types of emails:

  1. Weekly Newsletter setup as Automation on MailerLite (with a chain of 40 emails)
  2. Campaign emails about new courses, masterclasses and promotions.

There are also some segments on the MailerLite (ML) side; for them, we customize both types of emails:

  • Members (subscribers who have an active Membership on IxDF platform)
  • Non-members

We decided to completely separate these lists, so subscribers will have more control over the emails they receive. It is possible using MailerLite's Groups and Segments, but there is an issue: MailerLite adds unsubscribe links (tech: via List-Unsubscribe header aka "GMail top link") that unsubscribe a subscriber from all lists/groups. To bypass this limitation, we decided to use 2 MailerLite accounts; each will have their own subscribers:

  • IxDF Power (new): for the 1 Powerful Email Each Week weekly email (Automations)
  • IxDF News & Legacy: for Important News (Campaigns)

When a user subscribes on the https://ixdf.org site to the 1 Powerful Email Each Week list, the Laravel application will create 2 Subscriber records in its database (visible on Nova) and then send API requests to two MailerLite accounts to create appropriate Subscriber records on MailerLite.

We are going to deploy these big changes within the v5.0 (aka "Rebirth") release of the IxDF-web application that we are planning to do 2026.02.23.

The application in avg has 40–90 unique new subscribers every day, ~80/day average.

Mail Domains ​

We send the legacy list from interaction-design.org domain, and use the following senders:

  • rikke.friis.dam@interaction-design.org Rikke from IxDF (Interaction Design Foundation)
  • mads.soegaard@interaction-design.org Mads from IxDF (Interaction Design Foundation)

For the new setup, we will use separate "from" subdomains:

  • 1 Powerful Email Each Week:
    • power.ixdf.org (from rikke.friis.dam@power.ixdf.org) — for new subscribers only, subscribed after v5 release
    • power-for-members.ixdf.org (from rikke.friis.dam@power-for-members.ixdf.org) — for new subscribers only, subscribed after v5 release
  • Important News:
    • news.ixdf.org (from mads.soegaard@news.ixdf.org) — for new subscribers only, subscribed after v5 release
    • news-for-members.ixdf.org (from mads.soegaard@news-for-members.ixdf.org) — for new subscribers only, subscribed after v5 release
    • interaction-design.org (from mads.soegaard@interaction-design.org) — for existing subscribers only, we won't add new subscribers to this list/group (changed from rikke.friis.dam@interaction-design.org)

The two member-facing domains (power-for-members.ixdf.org and news-for-members.ixdf.org) are brand-new and require warming up if we move existing members onto them (see Open Questions). The non-member domains (power.ixdf.org and news.ixdf.org) start with 0 subscribers and grow organically, so warm-up is not needed.

Map of IxDF List IDs with MailerLite accounts and groups:

  1. LEGACY_LIST_ID = 1: group 105313679009908297 "Newsletter (Legacy)" on "IxDF News" account
  2. IMPORTANT_UPDATES_LIST_ID = 52: group 178057613546620683 "Important Updates" on "IxDF News" account
  3. POWERFUL_WEEKLY_EMAIL_LIST_ID = 53: group 179928400173991802 "1 Powerful Email Each Week" on "IxDF Power" account

Subscribing ​

There are a few subscription forms on https://ixdf.org that look like "1 Powerful Weekly Email" subscription, auto-subscribes to both lists (Power + Updates).

On subscription, for non-members IxDF-web application sends EmailConfirmationNeeded email, while Members don't need email confirmation. (⚙️ technically it creates 2 Subscriber records and then sends 2 API calls to MailerLite accounts).

Unsubscribing ​

There are a few ways to unsubscribe:

  • on the ixdf.org site
  • and directly from email.

Members have one more option: manage all emails from the Notification Settings panel.

We want to allow subscribers to manage their email lists on our site https://ixdf.org. To do it, added to the footer of emails links like https://ixdf.org/subscriptions/{$token}/preferences?unsubscribe=power, where {$token} is a variable that MailerLite auto-replace by the value from "Token" Custom Field added to the Subscriber profile.

We also decided to hide as much as possible native MailerLite's unsubscribe link, so subscribers will use our platform to manage subscribers more often. Additionally, MailerLite auto-adds a List-Unsubscribe header that uses MailerLite's unsubscribe link we don't have control over. Given this, every email has 3 unsubscribe links

  1. List-Unsubscribe header link (controlled by MailerLite)
  2. Our $token-based unique per subscriber link in the footer (controlled by IxDF)
  3. Built-in unsubscribe footer link that we visually hid (controlled by MailerLite)

Powerful Weekly account segments ​

  1. 🌲Power: Active Members — send from power-for-members.ixdf.org
  2. 🌲Power: Anyone Except Active Members — send from power.ixdf.org

Important News account segments ​

The "IxDF News" MailerLite account should have these segments/groups (number of active subscribers has been snapshotted 2026-02-25):

  1. 🦖 Legacy: Active Members — send from interaction-design.org (18,122 subscribers)
  2. 🦖 Legacy: Non-Members — send from interaction-design.org (182,535 subscribers)
  3. 🦖 Legacy: Canceled Members — send from interaction-design.org (91,657 subscribers)
  4. 🌲 News: Active Members — send from news-for-members.ixdf.org
  5. 🌲 News: Non-Members — send from news.ixdf.org
  6. 🌲 News: Canceled Members — send from interaction-design.org

Legacy segments receive the same campaigns as non-legacy, but from the old sender domain (during the warm-up period).

When a member cancels their membership, its subscriber on ML should be moved to the Cancelled members segment, NOT re-added to the non-members list.

Migration and Warm-up ​

Non-member domains (power.ixdf.org and news.ixdf.org) start with 0 subscribers and grow organically — no warm-up needed. Only member-facing domains need warm-up (power-for-members.ixdf.org and news-for-members.ixdf.org) because we need to move existing members onto them.

For "Power" and "News" lists we have ~74 new subscribers/day:

  • ~30% of them are Active Members (~22 members/day go directly to new domains after v5)
  • ~70% of them are Non-Members
  • Canceled Members do not subscribe lists: they move from Active Members lists

Warm-up plan ​

Total to migrate: 18,122 active members from 🦖 Legacy: Active Members to both:

  • 🌲 News: Active Members
  • 🌲 Power: Active Members

Approach:

  • Move subscribers in weekly batches, starting with the most engaged (highest open rates)
  • Once moved, a subscriber is removed from 🦖 Legacy: Active Members segment immediately (no overlap)
  • Migrated members start the Power chain from email #1
  • Both domains warm up in sync since each moved member lands on both lists
  • Monitor deliverability between batches: bounce rate must stay <2%, spam complaints <0.3%
  • If metrics degrade, pause the next batch and investigate before continuing

Email cadence per subscriber per week:

  • news-for-members.ixdf.org: ~1.3 campaign/week
  • power-for-members.ixdf.org: 1 automation email/week (7-day delay chain)

*Schedule (for -for-members lists):

WeekDatesBatchMigratedEst. total*News sendsPower sends
1Mar 2–5200200~350~1,050~350
2Mar 9–12300500~800~1,600~800
3Mar 16–201,0001,500~1,950~1,950~1,950
4Mar 23–261,5003,000~3,600~3,600~3,600
5Mar 30–Apr 32,0005,000~5,750~5,750~5,750
6Apr 6–105,00010,000~10,900~21,800~10,900
7Apr 13–178,12218,122~19,200~19,200~19,200

*Est. total includes ~154/week organic new member subscribers on top of migrated ones.

Week 7 completes the migration. If deliverability isn't solid by week 6, split the final batch across two weeks.

1 Powerful Weekly Email & Segments ​

It will be a brand-new chain of emails, Rikke will create the first few emails for it. Unlike the legacy Newsletter Chain, we use two separate MailerLite workflows (not a single chain with dynamic content blocks): one for Members and one for Non-members. The content between the two chains is completely different with zero overlap, so a subscriber who moves from non-member to member starts the member chain from email #1 without seeing duplicate content.

Cadence: One email per subscriber per week, sent every Wednesday. Each subscriber receives the next email in their chain (e.g., one batch gets email #1, another batch gets email #2, etc. — all on the same Wednesday).

Automation setup on MailerLite ​

Each automation uses a group-based trigger ("Subscriber joins group: 1 Powerful Email Each Week") with a condition gate that checks segment membership before sending:

  • Members automation: Trigger → Condition: "in Power: Active Members segment?" → Yes: continue chain / No: exit flow
  • Non-members automation: Trigger → Condition: "in Power: Anyone Except Active Members segment?" → Yes: continue chain / No: exit flow

The condition gate ensures only the correct audience receives each chain. It also acts as a safety net: if a subscriber's status changes mid-chain, the next condition check will exit them from the flow.

How membership transitions move subscribers between automations ​

The IxDF-web application controls transitions via the MailerLite API. The primary mechanism is subscribe/unsubscribe status — unsubscribed subscribers stop receiving all emails immediately, without needing to remove them from groups or automation queues.

Non-member becomes a Member:

  1. IxDF app updates membership_lifecycle_state field on the subscriber via API
  2. MailerLite segment "Power: Active Members" now includes this subscriber
  3. The non-member automation's condition gate ("in Power: Anyone Except Active Members?") evaluates to No at the next email step → subscriber exits the non-member chain
  4. IxDF app unsubscribes and re-subscribes the subscriber (with resubscribe: true) to re-trigger the group join → subscriber enters the member automation from email #1

Member cancels membership:

  1. IxDF app unsubscribes the subscriber from the Power account
  2. Unsubscribed status immediately stops all automation emails — no need to remove from groups or automation queues
  3. Subscriber moves to the Canceled Members segment (receives only occasional manual win-back emails)

Canceled member re-activates:

  1. IxDF app re-subscribes the subscriber (with resubscribe: true) and updates membership_lifecycle_state
  2. Re-subscribing to the group re-triggers the "Subscriber joins group" automation
  3. Condition gate confirms "in Power: Active Members" → subscriber enters the member chain from email #1

Legacy chain fix: The legacy chain had a bug where subscribers could never leave it regardless of their current status. The new setup fixes this: unsubscribing immediately stops all emails, and the condition gate acts as a secondary check before each email step.

We will stop Almanac newsletters upon v5 release.

Future of Legacy Newsletter List ​

Subscribers from this list received both email types. We remove "newsletter workflow" automation, they will ONLY receive "important news" campaign emails. Whether to move Legacy Members to the new "Important Updates" list is undecided (see Open Questions).

Subscriber Counters ​

The displayed subscriber count adds a hardcoded 300,000 to prevent the number from falling after cleanup. The landing page copy says "like XXX,XXX others" implying real subscribers.

Technical integration ​

There is 2-way sync between IxDF-web app and MailerLite accounts.

IxDF-web app sends an API request on changes on the application side:

  • New Subscriber Created
  • Subscriber changed subscription settings (from any page)
  • Subscriber updated its state:
    • membership status or type

MailerLite accounts send webhooks to the IxDF-web app on these events:

  • subscriber.unsubscribed
  • subscriber.bounced
  • subscriber.spam_reported

Note, IxDF-web application doesn't listen subscriber.deleted Webhook event and thus we should never remove subscribers from ML directly.

Known Trade-offs ​

Using two separate MailerLite accounts introduces the following trade-offs:

  1. No cross-account spam protection. MailerLite's built-in spam protection (e.g., "do not send email to a subscriber that already received something from us this week") does not work across accounts. A subscriber could receive emails from both accounts on the same day.
  2. Loss of historical statistics. Open rates, click rates, and other engagement data from the legacy account do not carry over to the new account.
  3. Loss of chain progress. Subscribers' progress in the legacy weekly email chain is not transferable — new chains start from email #1.

Reply Delivery (Google Workspace Aliases) ​

When subscribers reply to MailerLite emails, replies are delivered via Google Workspace email aliases. MX records for all 4 subdomains point to smtp.google.com, and Gmail is activated for each domain in Google Workspace Admin.

Subscriber replies toDelivered to
mads.soegaard@news.ixdf.orgmads.soegaard@interaction-design.org
mads.soegaard@news-for-members.ixdf.orgmads.soegaard@interaction-design.org
rikke.friis.dam@news.ixdf.orgrikke.friis.dam@interaction-design.org
rikke.friis.dam@news-for-members.ixdf.orgrikke.friis.dam@interaction-design.org
rikke.friis.dam@power.ixdf.orgrikke.friis.dam@interaction-design.org
rikke.friis.dam@power-for-members.ixdf.orgrikke.friis.dam@interaction-design.org

MailerLite Automation Caveats ​

Why group triggers + condition gates (not segment triggers) ​

MailerLite's "Joins a segment" trigger has limitations that conflict with our requirements:

  1. One-time trigger — A subscriber only enters the automation once. If they leave the segment and rejoin (e.g., canceled member re-activates), the automation does not re-trigger.
  2. No auto-removal — When a subscriber leaves a segment, MailerLite does not remove them from the in-progress automation.
  3. Segment evaluation delay — Segments are recalculated periodically, not in real-time.

We use group-based triggers instead, because:

  • The IxDF app can unsubscribe/re-subscribe to the group via API, which re-triggers the automation
  • Combined with a condition gate (segment membership check) at the start of the flow, only the correct audience proceeds
  • Unsubscribing immediately stops all emails without needing to manage automation queues

Condition gates as a safety net ​

Each automation has a condition step checking segment membership before every email. If a subscriber's membership_lifecycle_state changes mid-chain (synced by the IxDF app), the segment re-evaluates and the condition gate exits them from the flow at the next email step. This is a secondary safeguard — the primary mechanism is unsubscribe/re-subscribe.

Batch migration and throttling ​

The warm-up plan moves existing members in weekly batches (200 → 300 → 1,000 → ...) to the member group. Each batch triggers the automation simultaneously for all moved subscribers. Verify that MailerLite handles batch group joins without throttling or rate-limiting the automation trigger.

Verify: re-subscribe re-triggers automation ​

The transition flow relies on unsubscribing and re-subscribing (with resubscribe: true) to re-trigger the "Subscriber joins group" automation. Confirm that MailerLite treats a re-subscribe as a new group join that fires the automation from email #1.

Open Questions ​

  1. Move existing Member Subscribers from the Legacy list to new lists? Should we move existing members from the Legacy list (that use interaction-design.org as sender) to the new member-facing domains (power-for-members.ixdf.org, news-for-members.ixdf.org)? This requires warming up these domains first.
  2. Legacy list end-of-life. When and how does the Legacy list (LEGACY_LIST_ID = 1) get decommissioned? It currently only receives campaign emails — is there a timeline to sunset it entirely? (we can start to gradually move active subscribers (who open emails) once new domains reputation will be good enough).
  3. Reply-to address for campaign emails. What should the reply-to address be for campaign emails sent from the new domains? (e.g., should replies to mads.soegaard@news.ixdf.org go to a specific inbox?)