# Jak vytvořit onboardingovou e-mailovou sekvenci z aplikace Cursor

Kanonická URL: https://brew.new/cs/blog/how-to-create-an-email-onboarding-sequence-from-cursor
Autor: Philip Sørensen
Publikováno: 2026-09-25
Aktualizováno: 2026-09-29

Onboardingový e-mail závisí na stejných datech o událostech jako tvůj produkt. Když pracuješ z aplikace Cursor, můžeš na jednom místě projít obsluhu registrace, vytvořit odpovídající spouštěč v Brew a zkontrolovat e-mail. Za publikování sekvence a schvalování ostrých rozesílek ať ale dál odpovídá člověk.

## Připoj Brew

Přidej tento server do nastavení MCP v aplikaci Cursor nebo do souboru `.cursor/mcp.json` ve svém projektu:

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

Dokonči přihlášení do Brew přes OAuth a vyber správnou značku. Požádej agenta, ať zavolá `get_brew_capabilities`. Pokud tvůj klient používá jiný formát konfigurace, postupuj podle [návodu k nastavení klientů](https://docs.brew.new/api-reference/mcp/connect-your-client). API klíče do chatu ani do repozitáře nedávej.

## Podmínky pro registraci a připomínku definuj zvlášť

Požádej Cursor, ať najde kód, který nový účet ukládá do databáze. Rozhodni, co se počítá jako aktivace, třeba založení prvního projektu. Tento návod nechává kontrolu podmínek v aplikaci a používá dva samostatné spouštěče:

- Spouštěč registrace pro okamžité uvítání.
- Spouštěč připomínky pro ty, kdo splňují podmínky. Tvoje aplikace ho aktivuje až po kontrole aktuálního stavu aktivace.

Přes `save_trigger` nadefinuj payload každého spouštěče, včetně povinného řetězce s e-mailem. Ulož si skutečná ID spouštěčů, která se ti vrátí. Zobrazovaný název jako `user_signed_up` identifikátor pro API nenahradí.

## Vytvoř a zkontroluj e-maily

Užitečný první brief může vypadat takhle:

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

Agent může použít `create_email`, `edit_email` a `save_automation`. Výsledky otevři v Brew a zkontroluj rozvržení, texty, odkazy a odesílací doménu. Používej zdokumentovanou [syntaxi proměnných](https://docs.brew.new/create-emails/merge-tags) včetně otestované záložní hodnoty pro chybějící jméno.

Nedávej do lineární cesty filtr `activated is false` před navazující e-mail s podmínkou `activated is true`. Filtr, který neprojde, zastaví všechny navazující kroky. Pole události jako `payload.activated` se ani po čekání nemění. Jako alternativu k tomuto postupu s plánováním v aplikaci můžeš nadefinovat a synchronizovat pole kontaktu typu ano/ne a po každém relevantním čekání kontrolovat `contact.activated`. Tahle podmínka čte aktuální kontakt v Brew, ne databázi tvé aplikace. Víc najdeš v [průvodci sekvencí pro zkušební verze](/cs/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).

## Zapoj backend

Schéma každého spouštěče si stáhni přes `get_trigger_contract`, nebo schémata vygeneruj pomocí [CLI](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Spouštěč registrace aktivuj až po potvrzení (commitu) transakce, která zakládá účet.

Tento příklad pro shell předpokládá, že `BREW_SIGNUP_TRIGGER_ID` obsahuje identifikátor vrácený při vytvoření spouštěče a že jeho schéma deklaruje `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"}}'
```

Pro každou událost registrace použij stabilní klíč, ponech ho i pro opakované pokusy a neúspěšné odpovědi kontroluj. Řiď se [pravidly idempotence v API](https://docs.brew.new/api-reference/api/idempotency).

Když přijde čas na připomínku, tvoje aplikace načte aktuální stav účtu. Pokud je uživatel aktivovaný, smazaný nebo jinak nesplňuje podmínky, spouštěč připomínky neaktivuje. V opačném případě pošle novou událost s aktuálními daty. Samotná aktualizace pole kontaktu původní běh nezruší.

## Před publikováním testuj

Použij `test_automation` s příjemci, které máš pod kontrolou. Ověř si [aktuální chování testů](https://docs.brew.new/create-emails/build-an-automation) a projdi historii běhů. Otestuj i plánovač v aplikaci:

1. Nový účet dostane uvítání právě jednou.
2. Neaktivní účet, který podmínky splňuje, vyvolá jednu událost připomínky.
3. Účet aktivovaný před naplánovanou kontrolou žádnou událost připomínky nevyvolá.
4. Opakovaný pokus nevytvoří odeslání navíc.
5. Chybějící nebo neplatná pole vyvolají chybu, kterou tvůj backend zaznamená a ošetří.

Zkontroluj účel odesílací domény a požadavky na souhlas. Pak automatizaci výslovně publikuj přes `save_automation` s `published: true`. Publikovaná automatizace se může spustit na skutečné události.

O návrhu sekvence obecněji píšeme v článku o [uvítacích e-mailových sekvencích](/cs/blog/welcome-email-sequence). S volbou rozhraní pro tvůj backend ti pomůže článek [MCP vs. REST](/cs/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use).