# Jak stworzyć sekwencję e-maili onboardingowych w Cursor

Kanoniczny adres URL: https://brew.new/pl/blog/how-to-create-an-email-onboarding-sequence-from-cursor
Autor: Philip Sørensen
Opublikowano: 2026-09-25
Zaktualizowano: 2026-09-29

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:

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

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

## Podłącz backend

Pobierz schemat danych każdego wyzwalacza za pomocą `get_trigger_contract` albo wygeneruj schematy przez [CLI](https://docs.brew.new/api-reference/guides/typed-payload-contracts). 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`:

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

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

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](https://docs.brew.new/create-emails/build-an-automation) 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](/pl/blog/welcome-email-sequence). Wybór interfejsu dla backendu omawia wpis [MCP kontra REST](/pl/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use).