# How to create an email onboarding sequence from Cursor

Canonical: https://brew.new/blog/how-to-create-an-email-onboarding-sequence-from-cursor
Author: Philip Sørensen
Published: 2026-09-25
Updated: 2026-09-29

An onboarding email depends on the same event data as your product. Working from Cursor lets you review the signup handler, create the matching Brew trigger, and check the email in one place. Keep a person responsible for publishing the flow and approving live sends.

## Connect Brew

Add this server in Cursor's MCP settings or your project's `.cursor/mcp.json`:

```json
{
  "mcpServers": {
    "brew": { "url": "https://brew.new/api/mcp" }
  }
}
```

Complete Brew's OAuth sign-in and select the intended brand. Ask the agent to call `get_brew_capabilities`. Follow the [client setup guide](https://docs.brew.new/api-reference/mcp/connect-your-client) if your client uses a different configuration format. Keep any API keys out of the chat and repository.

## Define signup and reminder eligibility separately

Ask Cursor to locate the code that commits a new account. Decide what counts as activation, such as creating a first project. This walkthrough keeps eligibility checks in the application and uses two distinct triggers:

- A signup trigger for the immediate welcome.
- An eligible-reminder trigger that your application fires only after checking current activation state.

Use `save_trigger` to define each payload, including the required email string. Save the actual returned trigger IDs. A display name such as `user_signed_up` is not a substitute for the API identifier.

## Build and review the emails

A useful first brief is:

```text
Create a welcome email for a new account.
One action: create a first project at https://app.example.com/projects/new.
Use the brand already selected in Brew. Do not invent statistics or testimonials.
Create a separate setup-reminder email for recipients our app confirms have not activated.
Leave both automations as drafts for review.
```

The agent can use `create_email`, `edit_email`, and `save_automation`. Open the results in Brew and inspect the layout, copy, links, and sending domain. Use the documented [merge-tag syntax](https://docs.brew.new/create-emails/merge-tags), including a tested fallback for a missing name.

Do not put an `activated is false` filter in a linear path before an `activated is true` follow-up. A failed filter stops its descendants. Event fields such as `payload.activated` remain fixed after a wait. As an alternative to this application-scheduled recipe, define and sync a boolean contact field and check `contact.activated` after each relevant wait. That condition reads the current Brew contact, not your application database. See the [trial sequence guide](/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).

## Wire the backend

Fetch each trigger's contract with `get_trigger_contract`, or generate contracts using the [CLI](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Fire the signup trigger after your account transaction commits.

This shell example assumes `BREW_SIGNUP_TRIGGER_ID` contains the identifier returned when you created the trigger and that its schema declares `firstName`:

```bash
curl --fail-with-body \
  "https://brew.new/api/v1/automations/triggers/${BREW_SIGNUP_TRIGGER_ID}/fire" \
  -H "Authorization: Bearer ${BREW_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: signup-example-account-123" \
  -d '{"payload":{"email":"alex@example.com","firstName":"Alex"}}'
```

Use a stable key per signup event, retain it for retries, and inspect failed responses. Follow the [API idempotency contract](https://docs.brew.new/api-reference/api/idempotency).

When a reminder is due, your application reads the current account. If the user is activated, deleted, or otherwise ineligible, it does not fire the reminder trigger. Otherwise it sends a new event with current data. A contact-field update alone does not cancel the original run.

## Test before publishing

Use `test_automation` with controlled recipients. Check the [current test behavior](https://docs.brew.new/create-emails/build-an-automation) and inspect the execution history. Test the application scheduler too:

1. A new account receives the welcome once.
2. An inactive account produces one eligible reminder event.
3. An account activated before the scheduled check produces no reminder event.
4. A retry does not create an extra send.
5. Missing or invalid fields produce an error your backend records and handles.

Review the sending-domain purpose and consent requirements. Then publish explicitly with `save_automation` and `published: true`. A published automation can execute on real events.

For the broader sequence design, see [welcome email sequences](/blog/welcome-email-sequence). For choosing the interface your backend uses, see [MCP versus REST](/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use).