Automations

Automations are emails Brew sends in response to events in your business — a signup, a purchase, a payment failure. You build the flow once, and Brew runs it automatically whenever the trigger fires. One prompt → an automation that runs forever in the background. This is different from Campaigns, which are one-off sends you manually schedule to an audience. Not sure which to use? See Campaigns vs Automations.

Two types of automation

Marketing flows. Multi-step sequences like welcome flows, onboarding drips, abandoned-cart recovery, and re-engagement. These send over time and respect unsubscribes.
Transactional emails. Single, real-time emails like password resets, order receipts, and account notifications. These are always delivered — even to unsubscribed contacts — because they contain information the recipient needs.

Use a marketing flow when…	Use a transactional email when…
You want a sequence of emails over time	You want one email, sent immediately
Timing matters (wait 3 days, then send the next)	The email is essential — the user expects it right away
You want to branch based on engagement	The user is unsubscribed but still needs to receive it
Examples: welcome flow, onboarding, abandoned cart, win-back	Examples: password reset, order confirmation, login alert

Create a flow

Describe what you want

Open Home and tell Brew what to build. Be specific about purpose, length, and content.

“Build a 3-step welcome flow for new newsletter subscribers. Trigger when someone subscribes. First email: warm welcome and a link to top resources. Wait 3 days. Second email: a short story from a happy customer. Wait 4 days. Third email: nudge to upgrade with a 14-day trial.”

Review the generated flow

Brew opens the flow editor with the trigger, every email, every wait, and any filters or splits. You’ll see the flow diagram on the right and chat on the left.

Edit by talking or clicking

Two ways to edit:

In chat — “Add a 24-hour wait after the second email.” / “Make the third email more playful.” / “Split the flow based on whether they clicked the second email.”
In the diagram — click any node to open its config panel. Edit email content, change a wait duration, adjust a filter.

Activate

When the flow is ready, change its lifecycle status from Draft to Published. Once published, the next matching trigger event starts the flow.

Each flow run consumes credits. Email sends inside the flow count toward your monthly send limit.

Monitor runs

The Automations dashboard shows summary stats (Active, Runs, Sent, Issues) and per-flow details. Click into any flow to see its execution history and investigate failures.

The four node types

Every flow is built from four nodes plus a trigger. Send Email. Sends an email to the contact running through the flow. For each Send Email node, you can:

Generate a new email — provide a prompt and Brew writes it on-brand
Reuse an email from another flow — copies it into this flow

Best practice: keep each email focused on one outcome. Personalize using contact properties ({{{firstName}}}) and trigger payload values ({{@trigger:output.payload.orderId}}).

Wait. Pauses the flow for a set duration before continuing. Use to space out emails or give time for an action to happen. Choose from preset durations (1 hour, 1 day, 3 days, 1 week) or set a custom value.

Filter. Checks whether the contact matches a condition. If they match, they continue. If not, that branch ends for them. Filter on contact properties (plan = “pro”), behavior (opened the previous email), or trigger payload data.

Split. Splits the flow into two paths so contacts get different experiences. Each path is its own filter. Contacts go down whichever matches. Common pattern: split based on whether someone clicked an earlier email — engaged contacts get a deeper sequence, non-engaged contacts get a re-engagement nudge.

Triggers

Every automation needs a trigger — the event that starts the flow. In the flow editor, click the trigger node to pick from your existing trigger events or create a new one. Common trigger moments:

New user signup
Order placed
Trial ending soon
Payment failed
Cart abandoned
Subscription canceled

Lifecycle states

State	Meaning	Notes
Draft	Being created or edited. Not running.	Edit freely. Publish when ready.
Published	Live. New trigger events start the flow.	Pause to make edits.
Archived	Halted. No new runs will start.	Use when you want to fully stop a flow.

Pausing keeps the flow’s history intact and lets you resume later. Archiving is for flows you no longer need.

Personalization

Use merge tags anywhere in your emails to pull in contact or trigger data:

Source	Syntax	Example
Contact property	`{{{firstName}}}`	`Hi Alex,`
Custom property	`{{{plan}}}`	`Your Pro subscription`
Trigger payload	`{{@trigger:output.payload.orderId}}`	`Order #12345`
Fallback	`{{{firstName \| there}}}`	`Hi there,` (if no name)

Variable names are case-sensitive. {{{firstName}}} matches a payload field named firstName, not firstname. Mismatched names render as empty.

Common patterns

Welcome flow. Multi-step. Triggered when a new user signs up.

“Build a 3-step welcome flow triggered by user_signup. First email welcomes them and sets expectations. Second email sends a quick-start guide. Third email shares a customer success story.”

Abandoned cart. Multi-step. Triggered when a user adds to cart but doesn’t check out.

“Build an abandoned-cart flow for cart_abandoned. First email: friendly reminder with the items. Second email 24 hours later: address common objections. Third email 48 hours later: limited-time discount.”

Password reset. Transactional. Triggered when a user requests a reset.

“Create a password reset email triggered by password_reset_requested. Include the recipient’s first name and a resetUrl button. Keep it short and security-focused.”

Order confirmation. Transactional. Triggered when an order is placed.

“Create an order confirmation email triggered by order_placed. Include the recipient’s first name, order number, items, total, and shipping ETA.”

Re-engagement. Multi-step. Triggered on a schedule for inactive contacts.

“Build a 3-step re-engagement flow. First email: ‘We miss you’ with new features. Second email three days later: ask what content they’d prefer. Third email: final chance to stay subscribed.”

Trigger events

Trigger events are the signals that start your automations. Brew supports two kinds:

Custom events — events you define and send from your backend (e.g. user_signup, order_placed)
Built-in events — events automatically discovered from connected sources, like Stripe billing events

Manage both from the Settings link in the trigger panel, or press Cmd+K and search for Trigger events.

Custom events

Create the event

Open Trigger events from the trigger panel settings link or Cmd+K, then click Create event. Give it a clear, specific name.Good: user_signup, order_placed, subscription_renewed Avoid: event1, trigger, do_thing

Define the payload schema

Add the fields your event will send and mark which are required. Brew validates incoming events against this schema and rejects events that don’t match.Keep payloads flat. Avoid nested objects when you can — flat payloads are easier to use in email templates.Good:

{
  "email": "alex@example.com",
  "firstName": "Alex",
  "orderId": "ORD-12345",
  "plan": "pro"
}

Avoid:

{
  "user": { "email": "alex@example.com", "name": "Alex" },
  "order": { "id": "ORD-12345" }
}

Wire it up in your backend

Send events to Brew’s API with an API key (create one in Settings → API). See the API Reference for the exact contract.

Use it in an automation

In any automation, pick this event as the trigger. Brew populates the trigger node with your schema so you can reference payload fields in emails using {{@trigger:output.payload.fieldName}}.

Test before launch

Send a test event from the Trigger events page. The test runs through your published automations exactly like a real event would, so you can verify the flow end-to-end before going live.

Trigger best practices

Use descriptive event names. Names should describe the action. user_signup and order_placed are clear. event1 is not. Keep payloads flat and minimal. Flat payloads are easier to map to merge tags and easier to maintain. Only include fields you’ll actually use. Validate types in your schema. Mark fields as string, number, boolean, etc. Brew rejects invalid payloads before they trigger anything, surfacing problems early.

Connected-source events

Several integrations stream events into Brew automatically. Connecting a provider provisions the full event catalogue in one step — every supported event becomes a fireable trigger immediately. There’s no per-event enable step. The integration’s Manage tab (Integrations → click the provider) is a read-only catalogue plus a live Recent events stream so you can verify webhooks are flowing. Whether an event actually fires emails is gated entirely by whether at least one Published automation is wired to it. To stop an event from firing, unpublish the automation; to stop every event from the provider, disconnect the integration.

Source	What it covers	Event count
Clerk	User signups, organization activity, paid subscriptions, waitlist entries	13
Stripe	Subscriptions, invoices, checkouts, refunds, quotes	22
Stytch	Consumer (B2C) and B2B auth — user lifecycle, member changes, orgs	8
Supabase	`auth.users` raw and derived events (email confirmed, password changed, banned, …)	12
WorkOS	SSO users, password reset, organizations, SCIM directory sync	18
Shopify	Customer, order, checkout, cart, fulfillment	15
RevenueCat	In-app purchases + subscriptions across App Store, Play Store, Stripe, Web Billing	11

Once you’ve connected Stripe in Integrations, Brew automatically listens for the relevant Stripe events. You don’t need to configure them — they show up as available triggers in the automation builder. Brew supports these Stripe events as automation triggers:

checkout.session.async_payment_succeeded
checkout.session.async_payment_failed
checkout.session.completed
customer.created
customer.updated
customer.deleted
customer.subscription.created
customer.subscription.paused
customer.subscription.resumed
customer.subscription.trial_will_end
customer.subscription.deleted
invoice.paid
invoice.payment_failed
invoice.upcoming
quote.finalized
quote.accepted
quote.canceled

Common pattern: trigger a “payment failed” dunning sequence on invoice.payment_failed, or kick off an onboarding flow on customer.subscription.created.

Brew only listens for events from connected sources. It never charges customers, modifies subscriptions, refunds payments, mutates auth records, or changes Shopify orders.

Stripe events

Brew supports 22 Stripe events as automation triggers, across 6 categories: Checkout: checkout.session.completed, checkout.session.async_payment_succeeded, checkout.session.async_payment_failed Customer: customer.created, customer.updated, customer.deleted Subscription: customer.subscription.created, customer.subscription.updated, customer.subscription.paused, customer.subscription.resumed, customer.subscription.trial_will_end, customer.subscription.deleted Invoice: invoice.created, invoice.paid, invoice.payment_failed, invoice.upcoming Quote: quote.finalized, quote.accepted, quote.canceled Payment: charge.refunded, refund.created, payment_intent.payment_failed See Stripe in Integrations for the full setup walkthrough, personalization variables, and common patterns.

What happens when a payload fails validation

If an event arrives with missing required fields or wrong types, Brew returns a 400 INVALID_PAYLOAD error and does not start the automation:

{
  "error": {
    "code": "INVALID_PAYLOAD",
    "message": "Payload validation failed",
    "details": [
      { "field": "orderId", "message": "Required field 'orderId' is missing" }
    ]
  }
}

Fix the payload on your side and re-send.

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 analyze documentation with ChatGPT or Claude for deeper insights.

Two types of automation

Create a flow

The four node types

Triggers

Lifecycle states

Personalization

Common patterns

Trigger events

Custom events

Trigger best practices

Connected-source events

Stripe events

What happens when a payload fails validation

Need Help?

Search Documentation

ChatGPT/Claude Integration

Schedule a Call

Call Us Directly

Slack Channel

Email Support

Documentation Index

​Two types of automation

​Create a flow

​The four node types

​Triggers

​Lifecycle states

​Personalization

​Common patterns

​Trigger events

​Custom events

​Trigger best practices

​Connected-source events

​Stripe events

​What happens when a payload fails validation

​Need Help?

Search Documentation

ChatGPT/Claude Integration

Schedule a Call

Call Us Directly

Slack Channel

Email Support

Two types of automation

Create a flow

The four node types

Triggers

Lifecycle states

Personalization

Common patterns

Trigger events

Custom events

Trigger best practices

Connected-source events

Stripe events

What happens when a payload fails validation

Need Help?