# Zo maak je een e-mailreeks voor onboarding vanuit Cursor

Canonieke URL: https://brew.new/nl/blog/how-to-create-an-email-onboarding-sequence-from-cursor
Auteur: Philip Sørensen
Gepubliceerd: 2026-09-25
Bijgewerkt: 2026-09-29

Een onboardingmail hangt af van dezelfde eventdata als je product. Werk je vanuit Cursor, dan bekijk je de handler voor aanmeldingen, maak je de bijbehorende trigger in Brew aan en controleer je de e-mail, allemaal op één plek. Laat een persoon verantwoordelijk blijven voor het publiceren van de flow en het goedkeuren van live verzendingen.

## Koppel Brew

Voeg deze server toe in de MCP-instellingen van Cursor of in `.cursor/mcp.json` van je project:

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

Rond het inloggen via OAuth bij Brew af en kies het juiste merk. Vraag de agent om `get_brew_capabilities` aan te roepen. Volg de [handleiding voor het instellen van je client](https://docs.brew.new/api-reference/mcp/connect-your-client) als je client een ander configuratieformaat gebruikt. Houd API-sleutels uit de chat en uit je repository.

## Leg de aanmelding en de voorwaarden voor herinneringen apart vast

Vraag Cursor de code te vinden die een nieuw account vastlegt. Bepaal wat als activatie telt, zoals een eerste project aanmaken. In deze uitleg blijven de controles op wie in aanmerking komt in de applicatie, en gebruiken we twee aparte triggers:

- Een aanmeldtrigger voor de directe welkomstmail.
- Een herinneringstrigger voor wie in aanmerking komt, die je applicatie pas activeert nadat die de actuele activatiestatus heeft gecontroleerd.

Definieer elke payload met `save_trigger`, inclusief de verplichte string voor het e-mailadres. Bewaar de trigger-ID’s die je echt terugkrijgt. Een weergavenaam zoals `user_signed_up` is geen vervanging voor de ID in de API.

## Bouw en controleer de e-mails

Een nuttige eerste briefing:

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

De agent kan `create_email`, `edit_email` en `save_automation` gebruiken. Open de resultaten in Brew en controleer de lay-out, de tekst, de links en het verzenddomein. Gebruik de gedocumenteerde [syntaxis voor personalisatietags](https://docs.brew.new/create-emails/merge-tags), inclusief een geteste standaardwaarde voor een ontbrekende naam.

Zet in een lineair pad geen filter `activated is false` vóór een vervolgmail die `activated is true` vereist. Een filter waaraan niet wordt voldaan, stopt alle stappen die erop volgen. Eventvelden zoals `payload.activated` blijven na een wachtstap ongewijzigd. Als alternatief voor dit recept, waarin je applicatie de herinneringen inplant, kun je een booleaans contactveld definiëren en synchroniseren, en na elke relevante wachtstap `contact.activated` controleren. Die voorwaarde leest het actuele contact in Brew, niet de database van je applicatie. Zie de [gids over reeksen voor de proefperiode](/nl/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).

## Sluit de backend aan

Haal het contract van elke trigger op met `get_trigger_contract`, of genereer contracten met de [CLI](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Activeer de aanmeldtrigger nadat de transactie voor het account is vastgelegd.

Dit shellvoorbeeld gaat ervan uit dat `BREW_SIGNUP_TRIGGER_ID` de ID bevat die je terugkreeg toen je de trigger aanmaakte, en dat het schema `firstName` definieert:

```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"}}'
```

Gebruik per aanmeldevent een stabiele sleutel, bewaar die voor nieuwe pogingen en bekijk mislukte antwoorden. Volg het [idempotentiecontract van de API](https://docs.brew.new/api-reference/api/idempotency).

Is er een herinnering aan de beurt, dan leest je applicatie het actuele account. Is de gebruiker geactiveerd, verwijderd of komt die om een andere reden niet in aanmerking, dan activeert de applicatie de herinneringstrigger niet. Anders verstuurt ze een nieuw event met actuele data. Alleen een update van een contactveld annuleert de oorspronkelijke run niet.

## Test voordat je publiceert

Gebruik `test_automation` met ontvangers die je zelf in de hand hebt. Controleer [hoe testen op dit moment werkt](https://docs.brew.new/create-emails/build-an-automation) en bekijk de uitvoeringsgeschiedenis. Test ook de planner in je applicatie:

1. Een nieuw account krijgt de welkomstmail één keer.
2. Een inactief account levert één event op voor de herinneringstrigger.
3. Een account dat vóór de geplande controle is geactiveerd, levert geen herinneringsevent op.
4. Een nieuwe poging leidt niet tot een extra verzending.
5. Ontbrekende of ongeldige velden leveren een fout op die je backend vastlegt en afhandelt.

Controleer het doel van het verzenddomein en de eisen voor toestemming. Publiceer daarna expliciet met `save_automation` en `published: true`. Een gepubliceerde automatisering kan op echte events worden uitgevoerd.

Zie [welkomstreeksen](/nl/blog/welcome-email-sequence) voor het bredere ontwerp van de reeks. Zie [MCP versus REST](/nl/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use) voor de keuze van de interface die je backend gebruikt.