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:

{
  "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 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:

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, 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.

Wire the backend

Fetch each trigger's contract with get_trigger_contract, or generate contracts using the CLI. 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:

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.

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 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. For choosing the interface your backend uses, see MCP versus REST.