> ## Documentation Index
> Fetch the complete documentation index at: https://docs.brew.new/llms.txt
> Use this file to discover all available pages before exploring further.
# Automations
> Reference for Brew automations, including nodes, triggers, lifecycle states, merge tags, connected events, and validation errors.
Automations are emails Brew sends in response to events in your business, such as a signup, purchase, or payment failure. This page is the reference for the automation builder and the data it uses.
For the difference between one-off Emails and Automations, see [Emails vs Automations](/create-emails/emails-vs-automations). To create and publish a flow, follow [Build an Automation](/create-emails/build-an-automation).
## The Automations List
The **Automations** list shows every automation with its status and trigger, plus counts for total, live, and draft flows. Search automations, manage trigger events with **Triggers**, or start a flow with **New automation**.
Click an automation to open its dedicated canvas. The canvas always shows the flow selected from the list.
## The Four Node Types
Every flow has a trigger and four node types.
**Send Email.** Sends an email to the contact moving through the flow. The node can generate a new email or reference an email design from another flow.
Each contact that reaches a Send Email node produces one send with its own delivery and engagement events. Those sends appear in [analytics](/analytics/reading-analytics) alongside one-off sends. Personalize with contact properties such as `{{ firstName }}` or trigger values such as `{{ orderId }}`.
**Wait.** Pauses the flow before the next node. Choose a preset duration, such as 1 hour, 1 day, 3 days, or 1 week, or enter a custom value.
**Filter.** Continues a contact only when a condition matches. Conditions can use contact properties, behavior such as opening a previous email, or trigger payload data.
**Split.** Creates two filtered paths so contacts receive different experiences, often based on whether they clicked an earlier email.
## Triggers
Every automation has a trigger. The trigger picker offers connected-source events, custom HTTP triggers, and manual audiences.
Common trigger moments include new user signup, order placed, trial ending, payment failed, cart abandoned, and subscription canceled.
### Changing the Trigger
Click the trigger node to open its config panel. Use **Change trigger** to select another audience or event without rebuilding the rest of the flow.
### Manual Audience
A manual-audience automation runs a saved [audience](/audience/create-audiences) through the graph on demand. Its trigger shows the audience, filter query, and contact count. Runs show **Sending** while in flight and **Sent** when complete.
Manual-audience automations are one-off flows. Choose **Run now**, **Schedule**, or **Gradual send** when launching one. See [Send Options](/create-emails/send-options#when-you-launch-an-automation) for details.
The API and MCP also support manual-audience runs, including dry-runs.
## Lifecycle States
| State | Applies to | Meaning |
| ------------ | --------------------------- | ------------------------------------- |
| **Draft** | All automations | Being created or edited. Not running. |
| **Live** | Event-triggered automations | New matching events start the flow. |
| **Sending** | Manual-audience automations | A run is in flight. |
| **Sent** | Manual-audience automations | The run completed. |
| **Archived** | All automations | Halted. No new runs start. |
Each save or edit creates a version, shown in the canvas header as a version chip such as `v4`. Unpublishing keeps history and returns a live flow to Draft. Archiving stops a flow you no longer need.
## Personalization
Use merge tags in email content to pull in contact or trigger data:
| Source | Syntax | Example |
| ---------------- | -------------------------- | ------------------------ |
| Contact property | `{{ firstName }}` | `Hi Alex,` |
| Custom property | `{{ plan }}` | `Your Pro subscription` |
| Trigger payload | `{{ orderId }}` | `Order #12345` |
| Fallback | `{{ firstName \| there }}` | `Hi there,` (if no name) |
[Merge Tags](/create-emails/merge-tags) owns the full syntax, the fallback form, and the rules for what resolves.
## Trigger Events
Trigger events are signals that start automations.
* **Custom HTTP triggers.** Events you define and fire from your backend.
* **Built-in events.** Discovered from connected sources such as Stripe billing events.
Manage both from the **Settings** link in the trigger panel, or press **Cmd+K** and search for *Trigger events*.
See [Build an Automation](/create-emails/build-an-automation) for the same setup written as a step-by-step guide.
### Custom Events
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`
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:
```json theme={null}
{
"email": "alex@example.com",
"firstName": "Alex",
"orderId": "ORD-12345",
"plan": "pro"
}
```
Avoid:
```json theme={null}
{
"user": { "email": "alex@example.com", "name": "Alex" },
"order": { "id": "ORD-12345" }
}
```
Send events to Brew's API with an API key (create one in **Settings → API**). See the [API Reference](/api-reference/api/api-introduction) for the exact contract.
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 `{{ fieldName }}`.
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
Connecting a provider provisions its full event catalogue. The integration's **Manage** tab shows the catalogue and a **Recent events** stream.
An event fires emails only when a **Live** automation is wired to it. Unpublish the automation to stop its sends, or disconnect the integration to stop every event.
| Source | What it covers | Event count |
| --------------------------------------------- | ------------------------------------------------------------ | ----------- |
| [Clerk](/integrations/import/clerk) | User signups, organizations, subscriptions, waitlist entries | 13 |
| [Stripe](/integrations/import/stripe) | Subscriptions, invoices, checkouts, refunds, quotes | 22 |
| [Stytch](/integrations/import/stytch) | Consumer and B2B auth, members, organizations | 8 |
| [Supabase](/integrations/import/supabase) | `auth.users` and derived auth events | 12 |
| [WorkOS](/integrations/import/workos) | SSO users, password reset, organizations, SCIM | 18 |
| [Shopify](/integrations/import/shopify) | Customers, orders, checkouts, carts, fulfillment | 15 |
| [RevenueCat](/integrations/import/revenuecat) | In-app purchases and subscriptions | 11 |
See the [Integrations overview](/integrations/integrations) for the full list. Brew only listens to connected sources. It does not charge customers, modify subscriptions, refund payments, mutate auth records, or change Shopify orders.
### Stripe Events
Brew supports 22 Stripe events across checkout, customer, subscription, invoice, quote, and payment. See the [Stripe integration page](/integrations/import/stripe) for the full event list.
### What Happens When a Payload Fails Validation
If an event is missing a required field or has a wrong type, Brew returns a `400 INVALID_PAYLOAD` error and does not start the automation:
```json theme={null}
{
"error": {
"code": "INVALID_PAYLOAD",
"message": "Payload validation failed",
"details": [
{ "field": "orderId", "message": "Required field 'orderId' is missing" }
]
}
}
```
Fix the payload and send the event again. [Errors](/api-reference/api/errors) owns the envelope and the full code catalog.
## 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:
Type in the "Ask any question" search bar at the top left to instantly find relevant documentation pages.
Click "Open in ChatGPT" at the top right of any page to explore it further with ChatGPT or Claude.
Book time with our founders for personalized guidance on strategy, best practices, or complex implementation questions.
Need immediate assistance? Reach us at **+1-(332)-203-2145** for urgent issues or time-sensitive questions.
Our preferred support channel. You'll receive an invite after signup for direct founder support and fast responses.
Contact us at **[support@brew.new](mailto:support@brew.new)** for detailed inquiries or if you prefer not to use Slack.
Automations are emails Brew sends in response to events in your business, such as a signup, purchase, or payment failure. This page is the reference for the automation builder and the data it uses.
For the difference between one-off Emails and Automations, see [Emails vs Automations](/create-emails/emails-vs-automations). To create and publish a flow, follow [Build an Automation](/create-emails/build-an-automation).
## The Automations List
The **Automations** list shows every automation with its status and trigger, plus counts for total, live, and draft flows. Search automations, manage trigger events with **Triggers**, or start a flow with **New automation**.
Click an automation to open its dedicated canvas. The canvas always shows the flow selected from the list.
## The Four Node Types
Every flow has a trigger and four node types.
**Send Email.** Sends an email to the contact moving through the flow. The node can generate a new email or reference an email design from another flow.
Each contact that reaches a Send Email node produces one send with its own delivery and engagement events. Those sends appear in [analytics](/analytics/reading-analytics) alongside one-off sends. Personalize with contact properties such as `{{ firstName }}` or trigger values such as `{{ orderId }}`.
**Wait.** Pauses the flow before the next node. Choose a preset duration, such as 1 hour, 1 day, 3 days, or 1 week, or enter a custom value.
**Filter.** Continues a contact only when a condition matches. Conditions can use contact properties, behavior such as opening a previous email, or trigger payload data.
**Split.** Creates two filtered paths so contacts receive different experiences, often based on whether they clicked an earlier email.
## Triggers
Every automation has a trigger. The trigger picker offers connected-source events, custom HTTP triggers, and manual audiences.
Common trigger moments include new user signup, order placed, trial ending, payment failed, cart abandoned, and subscription canceled.
### Changing the Trigger
Click the trigger node to open its config panel. Use **Change trigger** to select another audience or event without rebuilding the rest of the flow.
### Manual Audience
A manual-audience automation runs a saved [audience](/audience/create-audiences) through the graph on demand. Its trigger shows the audience, filter query, and contact count. Runs show **Sending** while in flight and **Sent** when complete.
Manual-audience automations are one-off flows. Choose **Run now**, **Schedule**, or **Gradual send** when launching one. See [Send Options](/create-emails/send-options#when-you-launch-an-automation) for details.
The API and MCP also support manual-audience runs, including dry-runs.
## Lifecycle States
| State | Applies to | Meaning |
| ------------ | --------------------------- | ------------------------------------- |
| **Draft** | All automations | Being created or edited. Not running. |
| **Live** | Event-triggered automations | New matching events start the flow. |
| **Sending** | Manual-audience automations | A run is in flight. |
| **Sent** | Manual-audience automations | The run completed. |
| **Archived** | All automations | Halted. No new runs start. |
Each save or edit creates a version, shown in the canvas header as a version chip such as `v4`. Unpublishing keeps history and returns a live flow to Draft. Archiving stops a flow you no longer need.
## Personalization
Use merge tags in email content to pull in contact or trigger data:
| Source | Syntax | Example |
| ---------------- | -------------------------- | ------------------------ |
| Contact property | `{{ firstName }}` | `Hi Alex,` |
| Custom property | `{{ plan }}` | `Your Pro subscription` |
| Trigger payload | `{{ orderId }}` | `Order #12345` |
| Fallback | `{{ firstName \| there }}` | `Hi there,` (if no name) |
[Merge Tags](/create-emails/merge-tags) owns the full syntax, the fallback form, and the rules for what resolves.
## Trigger Events
Trigger events are signals that start automations.
* **Custom HTTP triggers.** Events you define and fire from your backend.
* **Built-in events.** Discovered from connected sources such as Stripe billing events.
Manage both from the **Settings** link in the trigger panel, or press **Cmd+K** and search for *Trigger events*.
See [Build an Automation](/create-emails/build-an-automation) for the same setup written as a step-by-step guide.
### Custom Events