E-mail onboardingowy zależy od tych samych danych o zdarzeniach co Twój produkt. Praca w Cursor pozwala w jednym miejscu przejrzeć kod obsługujący rejestrację, utworzyć pasujący wyzwalacz w Brew i sprawdzić e-mail. Niech jednak za publikację sekwencji i zatwierdzanie rzeczywistych wysyłek odpowiada konkretna osoba.

Połącz Brew

Dodaj ten serwer w ustawieniach MCP w Cursor albo w pliku .cursor/mcp.json swojego projektu:

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

Zaloguj się do Brew przez OAuth i wybierz właściwą markę. Poproś agenta o wywołanie get_brew_capabilities. Jeśli Twój klient używa innego formatu konfiguracji, skorzystaj z instrukcji konfiguracji klienta. Nie umieszczaj kluczy API na czacie ani w repozytorium.

Osobno określ warunki dla powitania i przypomnień

Poproś Cursor o znalezienie kodu, który zapisuje nowe konto w bazie danych. Zdecyduj, co uznajesz za aktywację, np. utworzenie pierwszego projektu. W tym przewodniku sprawdzanie warunków wysyłki odbywa się w aplikacji, a sekwencja korzysta z dwóch osobnych wyzwalaczy:

• Wyzwalacz rejestracji dla natychmiastowego powitania.
• Wyzwalacz przypomnienia dla kont spełniających warunki, który Twoja aplikacja wywołuje dopiero po sprawdzeniu bieżącego stanu aktywacji.

Za pomocą save_trigger zdefiniuj dane zdarzenia dla każdego wyzwalacza, w tym wymagany adres e-mail jako ciąg znaków. Zapisz identyfikatory wyzwalaczy faktycznie zwrócone przez Brew. Nazwa wyświetlana, np. user_signed_up, nie zastąpi identyfikatora w API.

Zbuduj i przejrzyj e-maile

Przydatny pierwszy brief wygląda tak:

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 może użyć create_email, edit_email i save_automation. Otwórz wyniki w Brew i sprawdź układ, treść, linki i domenę wysyłkową. Stosuj udokumentowaną składnię tagów personalizacji, w tym przetestowaną wartość zastępczą na wypadek braku imienia.

Nie umieszczaj filtra activated is false na liniowej ścieżce przed kolejnym e-mailem z warunkiem activated is true. Niespełniony filtr zatrzymuje wszystkie kroki, które po nim następują. Pola zdarzenia, takie jak payload.activated, po kroku oczekiwania pozostają niezmienione. Alternatywą dla tego przepisu, w którym przypomnienia planuje aplikacja, jest zdefiniowanie i synchronizowanie pola kontaktu typu prawda/fałsz oraz sprawdzanie contact.activated po każdym istotnym kroku oczekiwania. Taki warunek odczytuje bieżący kontakt w Brew, a nie bazę danych Twojej aplikacji. Zobacz poradnik o sekwencji e-maili w okresie próbnym.

Podłącz backend

Pobierz schemat danych każdego wyzwalacza za pomocą get_trigger_contract albo wygeneruj schematy przez CLI. Wywołuj wyzwalacz rejestracji dopiero po zatwierdzeniu transakcji, która tworzy konto.

Ten przykład dla powłoki zakłada, że BREW_SIGNUP_TRIGGER_ID zawiera identyfikator zwrócony przy tworzeniu wyzwalacza, a jego schemat deklaruje pole 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"}}'

Używaj stałego klucza dla każdego zdarzenia rejestracji, zachowuj go na potrzeby ponowień i sprawdzaj odpowiedzi z błędem. Postępuj zgodnie z kontraktem idempotentności API.

Gdy nadchodzi pora przypomnienia, Twoja aplikacja odczytuje bieżący stan konta. Jeśli użytkownik jest już aktywowany, usunięty lub z innego powodu nie spełnia warunków, aplikacja nie wywołuje wyzwalacza przypomnienia. W przeciwnym razie wysyła nowe zdarzenie z aktualnymi danymi. Sama aktualizacja pola kontaktu nie anuluje pierwotnego uruchomienia.

Przetestuj przed publikacją

Użyj test_automation z kontrolowaną grupą odbiorców. Sprawdź aktualne działanie testów i przejrzyj historię uruchomień. Przetestuj też harmonogram po stronie aplikacji:

1. Nowe konto dostaje powitanie dokładnie raz.
2. Nieaktywne konto generuje jedno zdarzenie przypomnienia.
3. Konto aktywowane przed zaplanowanym sprawdzeniem nie generuje zdarzenia przypomnienia.
4. Ponowienie nie tworzy dodatkowej wysyłki.
5. Brakujące lub nieprawidłowe pola powodują błąd, który Twój backend rejestruje i obsługuje.

Sprawdź przeznaczenie domeny wysyłkowej i wymagania dotyczące zgód. Potem jawnie opublikuj automatyzację przez save_automation z published: true. Opublikowana automatyzacja może się uruchamiać przy rzeczywistych zdarzeniach.

Szerzej o projektowaniu sekwencji przeczytasz we wpisie o sekwencjach powitalnych. Wybór interfejsu dla backendu omawia wpis MCP kontra REST.