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:

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

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

Zapoj backend

Schéma každého spouštěče si stáhni přes get_trigger_contract, nebo schémata vygeneruj pomocí CLI. 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:

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.

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ů 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. S volbou rozhraní pro tvůj backend ti pomůže článek MCP vs. REST.