Migrate from Postmark to Brew

​

Concepts

​

Check These Limits First

• 60 fires a minute. Trigger fires share the automation.runs.write rate limit: 60 requests per credential over a rolling 60 seconds. A busy receipt or reset stream can pass that. See Rate Limits.
• No attachments. Brew sends and trigger fires have no attachment field. A PDF invoice or a calendar invite can’t ride along.
• No delivery webhooks yet. Webhooks for delivery, open, and bounce events are on the roadmap. Today you poll GET /v1/sends and GET /v1/analytics/events instead.

​

1. Export Contacts, Consent, and Suppression

• Email, first name, last name, and any field your templates use
• Your marketing opt-in flag, with the date the person opted in, if your app stores one

​

Export Suppressions per Stream

​

2. Map Your CSV

• Postmark’s suppressions name the address field EmailAddress. In your CSV, call that column Email and add a Subscribed column set to false.
• Don’t import your opt-in flag as it is. Brew reads opt-outs only from a Subscribed column, so any other column becomes a plain custom property and those people import as subscribed.
• New columns become camelCase properties. A Plan Type column becomes planType. Use that name in merge tags and filters.
• Empty cells don’t overwrite existing data on update imports.
• Duplicate rows: the last one wins, so dedupe first.
• These names belong to built-in contact fields and can’t be used for custom properties: email, firstName, lastName, subscribed, createdAt, updatedAt, validationStatus, lastValidatedAt, importId, csvFileName.
• Save as UTF-8. Garbled characters at the mapping step usually mean it wasn’t.
• 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. Postmark stores no consent, so the evidence lives in your app: the signup checkbox, its label, and the opt-in date. 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, import over the API instead. POST /v1/contacts takes a consent record per contact, with the original date as capturedAt. It never changes Subscribed.

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

​

4. Rebuild Segmentation

​

5. Rebuild Templates and Merge Tags

​

Translate Merge Tags

• {{name}} becomes {{ trigger.name }}. Declare each field on the trigger, because an undeclared key never reaches the email. Names are case-sensitive.
• {{company.name}} becomes {{ trigger.company.name }}. Declare the nesting on the trigger. See Nested Payloads.
• {{{name}}} becomes {{ trigger.name }}. Triple braces aren’t merge tags in Brew, and publish refuses most of them.
• {{#each items}} … {{/each}} becomes {% for item in trigger.items %} … {% endfor %}. Inside the loop, Mustachio’s bare {{price}} becomes {{ item.price }}, and {{.}} becomes {{ item }}.
• A parent-scope tag such as {{../company_name}} becomes the full path, {{ trigger.company_name }}.
• {{#show_receipt}} … {{/show_receipt}} becomes {% if trigger.show_receipt %} … {% endif %}. An inverted {{^show_receipt}} becomes {% unless trigger.show_receipt %}.
• A value about the person, not the event, can come from the contact instead. Write {{ firstName | there }}, and the fallback after the pipe shows when the contact has no name on file.
• Delete {{{ @content }}} once the layout is folded in, and delete {{{ pm:unsubscribe }}}. Brew adds the unsubscribe link and your mailing address to every marketing email.

​

6. Rebuild Automations

​

7. Swap the API Calls in Your Code

await fetch('https://api.postmarkapp.com/email/withTemplate', {
  method: 'POST',
  headers: {
    Accept: 'application/json',
    'Content-Type': 'application/json',
    'X-Postmark-Server-Token': process.env.POSTMARK_SERVER_TOKEN,
  },
  body: JSON.stringify({
    From: "receipts@example.com",
    To: "user@example.com",
    TemplateAlias: "receipt",
    TemplateModel: {
      name: "Ada",
      order: { total: "$49.00", items: [{ name: "Pro seat", price: "$49.00" }] },
    },
    MessageStream: "outbound",
  }),
});

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@example.com",
        name: "Ada",
        order: { total: "$49.00", items: [{ name: "Pro seat", price: "$49.00" }] },
      },
    }),
  },
);

• To becomes the payload’s email. That’s the contact the automation runs for.
• TemplateModel becomes the rest of the payload, read in the email as {{ trigger.order.total }}.
• TemplateAlias, From, and MessageStream leave the call. The automation’s Send Email step holds the email, the subject, and the sending domain. The domain’s purpose does the job the stream did.
• Open and click tracking follow the sending domain’s settings, not a flag on each call.

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@example.com",
    firstName: "Ada",
    subscribed: true,
    consent: { source: "form", capturedAt: new Date().toISOString() },
  }),
});

​

8. Cut Over

1. Rebuild while Postmark keeps sending. Import contacts and rebuild audiences, templates, and automations. None of it touches live sending. Keep every Brew automation unpublished.
2. Check your segments. Confirm each Audience’s count against the query it replaces. See Step 4.
3. Refresh opt-outs. Right before your first Brew send, export each stream’s new suppressions from Postmark and import them as in Step 3. Repeat before each type you move, until Postmark stops sending. Anyone who opted out during the rebuild stays opted out.
4. Warm up with the first type you move. Stop sending that type through Postmark 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 event-driven marketing email. For each template, in order: publish the Brew automation, then switch that call in your code from Postmark to the Brew fire. Watch each in analytics before you move the next.
6. Move transactional email last. Skip this step for any stream a limit above rules out. 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. Receipts and resets 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 Postmark as a fallback. Leave the account and its server token in place for a couple of weeks, so you can switch a call back. Then downgrade or cancel. If you receive mail through an inbound stream, keep it on Postmark or move it to an inbound provider.

​

Quick Reference

​

Need Help?