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:

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

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

Sluit de backend aan

Haal het contract van elke trigger op met get_trigger_contract, of genereer contracten met de CLI. 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:

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.

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 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 voor het bredere ontwerp van de reeks. Zie MCP versus REST voor de keuze van de interface die je backend gebruikt.