# Så skapar du en mejlsekvens för onboarding från Cursor

Kanonisk URL: https://brew.new/sv/blog/how-to-create-an-email-onboarding-sequence-from-cursor
Författare: Philip Sørensen
Publicerad: 2026-09-25
Uppdaterad: 2026-09-29

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

```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](https://docs.brew.new/api-reference/mcp/connect-your-client) 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:

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

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](https://docs.brew.new/create-emails/merge-tags), 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](/sv/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).

## Koppla in backenden

Hämta varje utlösares kontrakt med `get_trigger_contract`, eller generera kontrakten med [CLI:t](https://docs.brew.new/api-reference/guides/typed-payload-contracts). 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`:

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

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](https://docs.brew.new/api-reference/api/idempotency).

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](https://docs.brew.new/create-emails/build-an-automation) 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](/sv/blog/welcome-email-sequence) för sekvensens upplägg i stort, och [MCP kontra REST](/sv/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use) när du ska välja vilket gränssnitt din backend använder.