Migrate from Customer.io to Brew

​

Concepts

​

1. Export Profiles, Consent, and Suppression

​

2. Map Your CSV

• Customer.io reserves a set of fixed-name attributes that won’t map 1:1 to Brew’s own reserved names, including id, cio_id, email, phone, created_at and unsubscribed. Rename collisions before mapping.
• Per-topic preferences live in a separate attribute, cio_subscription_preferences. Export it too if you use subscription topics. Someone who opted out of one topic imports as subscribed to all marketing, unless you mark them Subscribed: false or import them into the matching domain’s unsubscribe list.
• Don’t import unsubscribed as it is. Brew reads opt-outs only from a Subscribed column, so an unsubscribed column becomes a plain custom property and those people import as subscribed.
• created_at is skipped, because Brew manages its own creation date. Rename it, for example to cioCreatedAt, to keep the date.
• Dates: day-first dates such as 03/04/2026 (3 April) import correctly when you pick day first at the mapping step, and YYYY-MM-DD needs no choice. See date formats.

​

3. Import into Brew

​

Bring Your Consent Records

• Export the evidence. Include any opt-in date or subscription-preference attribute your Customer.io profiles carry. Keep those columns as custom properties.
• In the app, tick the consent checkbox at the review step. Brew records consent once for the whole file, dated the day you import.
• To keep each person’s original opt-in date, import over the API instead, with a consent record per contact. See Add Contacts for the consent fields.

{
  "contacts": [
    {
      "email": "jane@example.com",
      "consent": { "source": "import", "capturedAt": "2024-03-02T10:15:00Z", "evidence": "Customer.io signup form" }
    }
  ]
}

​

4. Rebuild Segmentation

​

5. Rebuild Templates and Merge Tags

​

Translate Merge Tags

• {{ customer.first_name | default: "there" }} becomes {{ customer.firstName | default: "there" }}. Brew field names are camelCase, and a snake_case name renders empty.
• {% if %}...{% else %}...{% endif %} conditionals, {% for %} loops, and filters render at send time.
• {{ trigger.order.total }} reads the nested payload you send with the fire, no flattening required.
• In an event-triggered campaign, {{ event.plan }} becomes {{ trigger.plan }}. Brew has no event. namespace.
• Customer.io-only tags and filters, such as add_day, format_number, unsubscribe_url and view_in_browser_url, need rewriting. Brew reads an unknown filter name as fallback text.

• Journey attributes ({{ journey.attribute }}), temporary values scoped to a single workflow run
• Object and relationship loops over Customer.io’s Objects ({% for class in objects.online_classes %}). Loops over payload data you send yourself work fine
• Snippets ({{ snippets.footer }}), reusable blocks, which you rebuild as standing instructions on your brand instead

​

6. Rebuild Automations

​

7. Swap the API Calls in Your Code

await cio.identify(userId, {
  email: user.email,
  first_name: user.firstName,
});
await cio.track(userId, {
  name: "trial_started",
  data: { plan: "pro" },
});

await fetch('https://brew.new/api/v1/contacts', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.BREW_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({ email: user.email, firstName: user.firstName, subscribed: false }),
});

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" },
    }),
  },
);

await cioApp.sendEmail(new SendEmailRequest({
  transactional_message_id: 44,
  to: user.email,
  identifiers: { id: user.id },
  message_data: { order: { total: 4900, items } },
}));

await fetch(
  `https://brew.new/api/v1/automations/triggers/${process.env.BREW_RECEIPT_TRIGGER_ID}/fire`,
  {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.BREW_API_KEY}`,
      'Content-Type': 'application/json',
      'Idempotency-Key': `receipt-${order.id}`,
    },
    body: JSON.stringify({
      payload: { email: user.email, order: { total: 4900, items } },
    }),
  },
);

// API-triggered broadcast
await cioApp.triggerBroadcast(
  broadcastId,
  { first_name: user.firstName },
  { segment: { id: segmentId } },
);

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

​

8. Cut Over

1. Rebuild while Customer.io keeps sending. Import contacts and rebuild segments, templates, and automations. None of it touches live sending. Keep every Brew automation unpublished.
2. Check your segments. Confirm each recreated Audience’s membership count against the original. See Step 4.
3. Refresh opt-outs. Right before your first Brew send, export Customer.io’s new unsubscribes and bounces and import them into Brew as Subscribed: false. That stops marketing only. Transactional sends still reach these contacts, so don’t fire transactional triggers for addresses that hard-bounced or complained. Repeat before each type you move, until Customer.io stops sending. Anyone who opted out during the rebuild stays opted out.
4. Warm up with the first type you move. Pause that type on Customer.io first, so nobody gets it from both. Send to your most engaged contacts first and ramp over several days. Gradual send does the ramping for you. No history means no reputation, even on a verified domain.
5. Move one type at a time. Broadcasts first, then automations. For each automation, in order: pause it on Customer.io, publish the Brew version, then point its signup forms, event tracking, or inbound integrations at Brew. Watch each in analytics before you move the next.
6. Move transactional messages last. Before you move any, add a separate transactional-purpose subdomain (see Transactional Email). A fire for a new address creates a subscribed contact, so only send marketing to people who opted in. They are the highest-stakes sends. Cut them over one at a time, and test-run each automation with a real payload before you point production code at its trigger.
7. Keep Customer.io as a fallback for a couple of weeks, then close it down once every message type has a clean week in Brew.

​

From an Agent or Code

“Import subscribed.csv, then unsubscribed.csv, as separate batches, and record the consent source as import.”

“Create an audience of subscribed contacts whose plan is pro, and tell me how many it holds.”

“Import this HTML as an editable email called Newsletter.”

• Contacts. POST /v1/contacts/import-csv, or brew-cli contacts import-csv --file contacts.csv, once per file. Add Contacts covers limits and the consent record.
• Segments. POST /v1/audiences with a name and filters, or brew-cli audiences create.
• Templates. POST /v1/emails/import with the format and content. Import is free and uses no AI.

​

Quick Reference

​

Need Help?