Migrate From Loops to Brew

Loops customers are usually more code-integrated than a typical marketing-tool switch. Events and per-recipient sends are often wired straight into application code through the API. Campaigns and workflows get built separately in the dashboard. Both halves move. Campaigns and workflows become Emails and Automations, and a Loops transactional email becomes a trigger plus a one-step automation sending from a transactional-purpose domain, which skips the unsubscribe footer and delivers to unsubscribed contacts. Step 7 covers the code swap for both kinds of call. It assumes your Brew brand and sending domain are already set up. If not, verify your domain first. DNS can take up to 72 hours. Rule for the whole migration: only one platform sends live email to a given contact at a time.

Concepts

Loops	Brew
Contact	Contact
Contact property	Custom property
Mailing list	Custom property plus an Audience filter, see Step 4
Filter / Segment	Audience (dynamic filter)
Campaign	Email
Workflow	Automation
Transactional email	Trigger plus a one-step automation on a transactional-purpose domain, see Step 7
Event	Trigger event (custom HTTP trigger or integration event)
`{tag}`, `{EVENT_PROPERTY:name}`	`{{ property \| fallback }}`
`transactionalId`, `dataVariables`	The `triggerEventId` you fire, and its `payload` fields, see Step 7

1. Export Contacts From Loops

Every marketing recipient must have opted in to hear from you. Importing or syncing contact data into Brew is not permission to email it. See What You Can Send.

Audience page → filter to a segment if you want a subset → Export. Loops writes one CSV of whatever’s in view, with columns for default and custom properties only. There’s no separate export per subscription status, so filter by Subscribed first if you only want active contacts. Carries over cleanly: email, name, source, custom properties, and subscribed (true/false). Mailing list membership doesn’t carry over automatically. Loops’ export includes contact properties, not list membership. A straight export and import won’t preserve which lists someone belonged to. If that matters, filter to each list and export it separately, then reconstruct it in Step 4. Event history and workflow enrollment state don’t carry over either. Those live in Loops with no Brew equivalent to import into. In Loops, unsubscribing blocks campaigns and workflows. Brew’s marketing sends respect the same flag, so the behavior your subscribed contacts expect doesn’t change.

2. Map Your CSV

Column	Required
`Email`	Yes
`First Name`, `Last Name`	Recommended
`Subscribed` (`true`/`false`)	No, defaults `true`
Anything else	Becomes a custom property automatically

Notes:

userGroup and any custom properties become Brew custom properties. Bring userId too if anything downstream matches on it
These names are reserved and can’t be used for custom properties: email, first_name, last_name, subscribed, created_at, updated_at, validation_status, last_validated_at, import_id
Mailing list membership needs its own export per list (see Step 1), then its own import into the matching property. It won’t ride along with a general contact import

Personalization. Loops uses single curly braces. {firstName} works in campaigns and workflows, and {EVENT_PROPERTY:name} in workflow emails triggered by events. The first becomes Brew’s {{ firstName | there }}. The property name is case-sensitive, and the fallback shows when the value is missing. The second becomes a trigger payload reference, written the same way: {{ orderId }}. See merge tags. {DATA_VARIABLE:name} lives in Loops transactional emails. In Brew it’s a trigger payload reference like the rest: {{ name }}, or {{ trigger.name }} if you prefer the namespaced form. One difference worth knowing: in Loops, a missing property value with no fallback means the email doesn’t send. In Brew the fallback lives inside the tag itself. There’s no separate step where you could forget one and have a send fail silently.

3. Import Into Brew

Audience → Add contacts → CSV Upload. Map columns, tick validation if the list hasn’t been checked recently, review, then import. Full import behavior is in Add Contacts.

4. Rebuild Segmentation

Filters and Segments map to Brew Audiences, dynamic filters over contact properties, email engagement, and subscription status. Describe one in plain English or build the filters by hand. Mailing Lists don’t have a direct equivalent. Brew has one subscription state per contact, subscribed or unsubscribed. There are no opt-in categories and no subscriber-facing preference center. Marketing emails and automations respect that flag. Rebuild each list as a custom property plus an Audience filtered on it. You keep the targeting, but membership is yours to manage. Contacts can’t pick lists for themselves, and unsubscribing opts them out of all marketing email rather than one list. If a Loops list carried a real consent distinction, decide how to honor it before your first send.

5. Rebuild Templates

You have	Use in Brew
A Loops campaign or workflow email	Screenshot it and use Upload image to recreate, or prompt Brew directly
Custom MJML	No direct MJML import. Rebuild in Brew’s editor or upload the rendered HTML
A Figma source	Connect with Figma

Open Emails in the sidebar, then use the Import tools on the right side of the canvas. See Importing existing designs. Loops themes, the shared styling across transactional emails, don’t carry over as a concept. Brew’s brand identity replaces the need for a manually maintained theme. Set it once and every rebuilt template inherits your logo, colors, fonts, and voice.

6. Rebuild Workflows as Automations

Loops trigger	Brew equivalent
Contact added (fires on new contacts from an integration, form, or API, not CSV)	Integration event if the source is a native Brew integration such as Stripe, Clerk, or Shopify, otherwise a custom HTTP trigger fired from your own signup endpoint
Contact updated	Custom HTTP trigger fired from your own update logic
Contact added to list	Custom HTTP trigger fired when you set the matching property
Event received	Custom HTTP trigger, or an integration event if it’s already a native Brew integration

Loops has a trick for re-running an existing contact through a workflow. Download a CSV, then re-upload it with “Trigger workflows” toggled on. That maps to a manual-audience run in Brew, the one-off, on-demand option, not a live trigger. Manual-audience automations are launched with POST /v1/automations/{automationId}/run rather than published. Branches become Filter or Split nodes, and delay steps become Wait nodes. Test-fire before publishing, and leave every rebuilt automation unpublished until cutover. That’s what prevents a double-send.

7. Swap Your Code Over to Triggers

Your Loops code has two kinds of call, and both land on the same fire endpoint. sendEvent calls become trigger fires. A cart-abandonment or trial-ending email is a marketing send fired per recipient by a custom event. In Brew that’s a trigger event plus an automation, and every per-recipient marketing send goes through it. sendTransactionalEmail calls move the same way. A reset, magic link, or receipt becomes a trigger plus a one-step automation whose Send Email node uses a transactional-purpose sending domain, which is what skips the unsubscribe footer and delivers to unsubscribed contacts. transactionalId maps to the triggerEventId you fire, and each dataVariables key becomes a payload field the email references as {{ trigger.* }}. The setup and fire call are identical to the marketing events below; only the domain on the send node differs. Set each marketing event up once:

POST /v1/automations/triggers to create the trigger event, for example “Trial started”. Capture the triggerEventId. You can also create it in-app from Trigger events.
POST /v1/emails to generate the email design. Capture both the emailId and the emailVersionId.
GET /v1/domains for a verified domainId.
POST /v1/automations with a Send Email node wired to that trigger. Each sendEmail node carries emailId, emailVersionId, domainId, subject, and previewText.
PATCH /v1/automations/{automationId} with { "published": true }.
Replace the Loops sendEvent call in your backend with a fire request.

Before, with Loops:

await loops.sendEvent({
  email: user.email,
  eventName: "trial_started",
  eventProperties: { plan: "pro" },
});

After, with Brew:

await fetch(
  `https://brew.new/api/v1/automations/triggers/${process.env.BREW_TRIAL_STARTED_TRIGGER_ID}/fire`,
  {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.BREW_API_KEY}`,
      'Content-Type': 'application/json',
      'Idempotency-Key': `trial-started-${subscription.id}`,
    },
    body: JSON.stringify({
      payload: { email: user.email, plan: "pro" },
    }),
  },
);

Set an Idempotency-Key on every retried call, the same discipline you used in Loops. Derive it from something stable about the action, like the subscription id above. A key built from a timestamp changes on every retry, which defeats the point and lets a retry send twice. Idempotency covers the replay window and conflict behavior. Full request shapes are in the API reference. This is the shape of the migration, not a copy-paste replacement for it.

8. Cut Over

Move one email type at a time.

Warm up your Brew sending domain before any real volume, most engaged contacts first, ramped over several days. Gradual send does the ramping for you.
Import contacts and rebuild templates and automations while Loops keeps sending everything as normal.
Cut over your lowest-risk campaign first, a newsletter, to confirm delivery and rendering.
Move workflows one at a time, once their triggers are confirmed firing correctly. Watch each one in analytics before moving the next.
Point signup forms and inbound integrations at Brew once everything upstream is verified.
Move transactional email last. Resets and magic links are the highest-stakes sends, so cut them over one at a time, test-running each automation with a real payload before pointing production code at its trigger. Close Loops down once every send type has a clean week in Brew.

Never leave the same email type live in both places at once. That’s how a contact gets the same campaign twice.

Quick Reference

Task	Where in Brew
Import contacts	Audience → Add contacts → CSV Upload
Build a segment	Audience → Create Audience
Import a template	Emails → canvas → Import
Build a flow	Automations in the sidebar
Create a trigger event	Trigger events, or `POST /v1/automations/triggers`
API keys	Settings → API

Need Help?

Our team is ready to support you at every step of your journey with Brew. Choose the option that works best for you:

Self-Service Tools
Talk to Our Team

Search Documentation

Type in the “Ask any question” search bar at the top left to instantly find relevant documentation pages.

ChatGPT/Claude Integration

Click “Open in ChatGPT” at the top right of any page to explore it further with ChatGPT or Claude.

Brew University

Recipes

Migrate to Brew

Migrate From Loops to Brew

Concepts

1. Export Contacts From Loops

2. Map Your CSV

3. Import Into Brew

4. Rebuild Segmentation

5. Rebuild Templates

6. Rebuild Workflows as Automations

7. Swap Your Code Over to Triggers

8. Cut Over

Quick Reference

Need Help?

Search Documentation

ChatGPT/Claude Integration

Schedule a Call

Call Us Directly

Slack Channel

Email Support

​Concepts

​1. Export Contacts From Loops

​2. Map Your CSV

​3. Import Into Brew

​4. Rebuild Segmentation

​5. Rebuild Templates

​6. Rebuild Workflows as Automations

​7. Swap Your Code Over to Triggers

​8. Cut Over

​Quick Reference

​Need Help?

Search Documentation

ChatGPT/Claude Integration

Schedule a Call

Call Us Directly

Slack Channel

Email Support

Concepts

1. Export Contacts From Loops

2. Map Your CSV

3. Import Into Brew

4. Rebuild Segmentation

5. Rebuild Templates

6. Rebuild Workflows as Automations

7. Swap Your Code Over to Triggers

8. Cut Over

Quick Reference

Need Help?