# Onboarding-E-Mail-Sequenz aus Cursor erstellen

Kanonische URL: https://brew.new/de/blog/how-to-create-an-email-onboarding-sequence-from-cursor
Autor: Philip Sørensen
Veröffentlicht: 2026-09-25
Aktualisiert: 2026-09-29

Eine Onboarding-E-Mail hängt an denselben Event-Daten wie dein Produkt. Wenn du aus Cursor heraus arbeitest, prüfst du den Handler für die Registrierung, legst den passenden Trigger in Brew an und kontrollierst die E-Mail, alles an einem Ort. Das Veröffentlichen des Flows und die Freigabe von Live-Versänden bleiben trotzdem in der Verantwortung eines Menschen.

## Brew verbinden

Füg diesen Server in den MCP-Einstellungen von Cursor oder in der Datei `.cursor/mcp.json` deines Projekts hinzu:

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

Schließ die OAuth-Anmeldung bei Brew ab und wähl die gewünschte Marke. Bitte den Agenten, `get_brew_capabilities` aufzurufen. Nutzt dein Client ein anderes Konfigurationsformat, folge der [Anleitung zur Einrichtung der Clients](https://docs.brew.new/api-reference/mcp/connect-your-client). Halte API-Keys aus dem Chat und aus dem Repository heraus.

## Registrierung und Bedingungen für Erinnerungen getrennt festlegen

Lass Cursor den Code finden, der ein neues Konto in der Datenbank festschreibt. Leg fest, was als Aktivierung zählt, etwa das Anlegen eines ersten Projekts. Dieser Walkthrough lässt die Bedingungsprüfungen in der Anwendung und nutzt zwei getrennte Trigger:

- Einen Registrierungs-Trigger für die sofortige Willkommens-E-Mail.
- Einen Erinnerungs-Trigger für Kontakte, die die Bedingungen erfüllen. Deine Anwendung löst ihn erst aus, nachdem sie den aktuellen Aktivierungsstatus geprüft hat.

Definiere mit `save_trigger` jede Payload, einschließlich des erforderlichen E-Mail-Strings. Speichere die tatsächlich zurückgegebenen Trigger-IDs. Ein Anzeigename wie `user_signed_up` ersetzt nicht die ID für die API.

## Die E-Mails bauen und prüfen

Ein brauchbares erstes 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.
```

Der Agent kann `create_email`, `edit_email` und `save_automation` nutzen. Öffne die Ergebnisse in Brew und prüf Layout, Texte, Links und Versanddomain. Nutze die dokumentierte [Syntax für Merge-Tags](https://docs.brew.new/create-emails/merge-tags), samt einem getesteten Fallback für einen fehlenden Namen.

Setz in einem linearen Pfad keinen Filter `activated is false` vor ein Follow-up mit `activated is true`. Ein Filter, den ein Kontakt nicht besteht, beendet alle nachfolgenden Schritte. Event-Felder wie `payload.activated` bleiben auch nach einer Wartezeit unverändert. Als Alternative zu diesem Rezept, bei dem deine Anwendung den Zeitplan steuert, kannst du ein boolesches Kontaktfeld anlegen und synchronisieren und nach jeder relevanten Wartezeit `contact.activated` prüfen. Diese Bedingung liest den aktuellen Kontakt in Brew, nicht deine Anwendungsdatenbank. Mehr dazu im [Leitfaden zur Testphasen-Sequenz](/de/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).

## Das Backend anbinden

Hol den Payload-Vertrag jedes Triggers mit `get_trigger_contract` ab oder generiere die Verträge mit der [CLI](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Löse den Registrierungs-Trigger aus, nachdem die Transaktion für das neue Konto abgeschlossen ist.

Dieses Shell-Beispiel setzt voraus, dass `BREW_SIGNUP_TRIGGER_ID` die ID enthält, die du beim Anlegen des Triggers zurückbekommen hast, und dass sein Schema `firstName` deklariert:

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

Nutze pro Registrierungs-Event einen stabilen Key, behalte ihn für Wiederholungen und sieh dir fehlgeschlagene Antworten an. Halte dich an die [Idempotenz-Regeln der API](https://docs.brew.new/api-reference/api/idempotency).

Wenn eine Erinnerung fällig ist, liest deine Anwendung das aktuelle Konto. Ist der Nutzer aktiviert, gelöscht oder erfüllt er die Bedingungen aus einem anderen Grund nicht, löst sie den Erinnerungs-Trigger nicht aus. Andernfalls sendet sie ein neues Event mit aktuellen Daten. Eine Aktualisierung eines Kontaktfelds allein bricht die ursprüngliche Ausführung nicht ab.

## Vor dem Veröffentlichen testen

Nutze `test_automation` mit Empfängern, die du kontrollierst. Prüf das [aktuelle Testverhalten](https://docs.brew.new/create-emails/build-an-automation) und sieh dir den Ausführungsverlauf an. Teste auch den Scheduler deiner Anwendung:

1. Ein neues Konto bekommt die Willkommens-E-Mail genau einmal.
2. Ein inaktives Konto erzeugt genau ein Erinnerungs-Event, für das die Bedingungen erfüllt sind.
3. Ein Konto, das vor der geplanten Prüfung aktiviert wurde, erzeugt kein Erinnerungs-Event.
4. Eine Wiederholung führt nicht zu einem zusätzlichen Versand.
5. Fehlende oder ungültige Felder erzeugen einen Fehler, den dein Backend protokolliert und behandelt.

Prüf den Versandzweck der Domain und die Anforderungen an die Einwilligung. Veröffentliche dann ausdrücklich mit `save_automation` und `published: true`. Eine veröffentlichte Automatisierung kann bei echten Events ausgeführt werden.

Zum Design der Sequenz insgesamt siehe den Beitrag zur [Willkommensserie](/de/blog/welcome-email-sequence). Welche Schnittstelle dein Backend nutzen sollte, klärt [MCP vs. REST](/de/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use).