Ett onboardingmejl är beroende av samma händelsedata som din produkt. När du arbetar från Cursor kan du granska koden som hanterar registreringen, skapa motsvarande utlösare i Brew och kontrollera mejlet på ett och samma ställe. Låt en person ansvara för att publicera flödet och godkänna skarpa utskick.

Anslut Brew

Lägg till den här servern i MCP-inställningarna i Cursor eller i projektets .cursor/mcp.json:

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

Slutför inloggningen med OAuth i Brew och välj rätt varumärke. Be agenten att anropa get_brew_capabilities. Följ guiden för att konfigurera klienter om din klient använder ett annat konfigurationsformat. Håll eventuella API-nycklar borta från chatten och repot.

Definiera registreringen och villkoren för påminnelser separat

Be Cursor att hitta koden som sparar ett nytt konto. Bestäm vad som räknas som aktivering, till exempel att skapa ett första projekt. Den här genomgången håller kontrollerna av vem som ska få mejlen i applikationen och använder två separata utlösare:

• En utlösare för registreringen, som startar välkomstmejlet direkt.
• En utlösare för påminnelser, som din applikation bara skickar händelser till efter att ha kontrollerat den aktuella aktiveringsstatusen.

Använd save_trigger för att definiera varje nyttolast, inklusive den obligatoriska strängen med e-postadressen. Spara de faktiska utlösar-ID:n som returneras. Ett visningsnamn som user_signed_up ersätter inte API-identifieraren.

Bygg och granska mejlen

En användbar första brief kan se ut så här:

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.

Agenten kan använda create_email, edit_email och save_automation. Öppna resultatet i Brew och granska layout, text, länkar och avsändardomän. Använd den dokumenterade syntaxen för personaliseringstaggar, inklusive ett testat reservvärde för ett namn som saknas.

Placera inte ett filter med activated is false i en rak väg före en uppföljning med activated is true. Ett filter som kontakten inte klarar stoppar alla steg efter filtret. Händelsefält som payload.activated ändras inte efter en väntetid. Som alternativ till det här receptet, där applikationen schemalägger påminnelserna, kan du definiera och synka ett booleskt kontaktfält och kontrollera contact.activated efter varje relevant väntetid. Villkoret läser den aktuella kontakten i Brew, inte din applikations databas. Läs guiden om sekvenser för provperioder.

Koppla in backenden

Hämta varje utlösares kontrakt med get_trigger_contract, eller generera kontrakten med CLI:t. Skicka händelsen till registreringsutlösaren när transaktionen som skapar kontot har genomförts.

Det här skalexemplet förutsätter att BREW_SIGNUP_TRIGGER_ID innehåller identifieraren som returnerades när du skapade utlösaren, och att utlösarens schema deklarerar 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"}}'

Använd en stabil nyckel per registreringshändelse, behåll den vid nya försök och granska svaren på misslyckade anrop. Följ API:ets kontrakt för idempotens.

När det är dags för en påminnelse läser din applikation det aktuella kontot. Om användaren är aktiverad, raderad eller av något annat skäl inte uppfyller villkoren skickar applikationen ingen händelse till påminnelseutlösaren. Annars skickar den en ny händelse med aktuell data. En uppdatering av ett kontaktfält avbryter inte ensam den ursprungliga körningen.

Testa innan du publicerar

Använd test_automation med kontrollerade mottagare. Kontrollera hur testerna fungerar i dag och granska körningshistoriken. Testa också schemaläggaren i applikationen:

1. Ett nytt konto får välkomstmejlet en gång.
2. Ett inaktivt konto ger en enda påminnelsehändelse.
3. Ett konto som aktiveras före den schemalagda kontrollen ger ingen påminnelsehändelse.
4. Ett nytt försök skapar inget extra utskick.
5. Saknade eller ogiltiga fält ger ett fel som din backend loggar och hanterar.

Se över avsändardomänens syfte och kraven på samtycke. Publicera sedan uttryckligen med save_automation och published: true. En publicerad automatisering kan köras på riktiga händelser.

Läs guiden om välkomstsekvenser för sekvensens upplägg i stort, och MCP kontra REST när du ska välja vilket gränssnitt din backend använder.