Migrate From Loops to Brew

Move contacts, campaigns, and workflows from Loops into Brew, with the API swap, a cutover that avoids double-sends, and what stays behind for now.

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.

One thing to know before you start: Brew’s transactional email isn’t generally available yet. Password resets, magic links, 2FA codes, and receipts stay in Loops for now. This guide migrates the marketing half, campaigns and workflows, and Step 7 covers what to do with the transactional code.

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	Not mappable yet: Brew’s transactional email isn’t GA. Keep it in Loops, see Step 7
Event	Trigger event (custom HTTP trigger or integration event)
{tag}, {EVENT_PROPERTY:name}	{{ property | fallback }}
transactionalId, dataVariables	No Brew equivalent yet, stays in your Loops code, 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 only in Loops transactional emails, which stay in Loops for now.

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 they migrate differently.

sendEvent calls move to Brew now. 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 stay in Loops for now. Brew’s transactional email isn’t generally available yet. Leave resets, magic links, and receipts pointed at Loops until it is. When it ships, those calls will follow the same trigger pattern as everything below.

Set each marketing event up once:

1. 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.
2. POST /v1/emails to generate the email design. Capture both the emailId and the emailVersionId.
3. GET /v1/domains for a verified domainId.
4. POST /v1/automations with a Send Email node wired to that trigger. Each sendEmail node carries emailId, emailVersionId, domainId, subject, and previewText.
5. PATCH /v1/automations/{automationId} with { "published": true }.
6. 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.

1. 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.
2. Import contacts and rebuild templates and automations while Loops keeps sending everything as normal.
3. Cut over your lowest-risk campaign first, a newsletter, to confirm delivery and rendering.
4. Move workflows one at a time, once their triggers are confirmed firing correctly. Watch each one in analytics before moving the next.
5. Point signup forms and inbound integrations at Brew once everything upstream is verified.
6. Transactional email stays in Loops, so keep the plan that covers it. Downgrade the rest once the marketing side is confirmed, and revisit when Brew’s transactional email is generally available.

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	Emails → Automations tab
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

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.

Talk to Our Team

Schedule a Call

Book time with our founders for personalized guidance on strategy, best practices, or complex implementation questions.

Call Us Directly

Need immediate assistance? Reach us at [phone] for urgent issues or time-sensitive questions.

Slack Channel

Our preferred support channel. You’ll receive an invite after signup for direct founder support and fast responses.

Email Support

Contact us at [e-mail] for detailed inquiries or if you prefer not to use Slack.