# Come creare una sequenza email di onboarding da Cursor

URL canonico: https://brew.new/it/blog/how-to-create-an-email-onboarding-sequence-from-cursor
Autore: Philip Sørensen
Pubblicato: 2026-09-25
Aggiornato: 2026-09-29

Un’email di onboarding dipende dagli stessi dati sugli eventi del tuo prodotto. Lavorando da Cursor puoi rivedere il codice che gestisce la registrazione, creare il trigger di Brew corrispondente e controllare l’email in un unico posto. Affida a una persona la responsabilità di pubblicare il flusso e di approvare gli invii reali.

## Collega Brew

Aggiungi questo server nelle impostazioni MCP di Cursor o nel file `.cursor/mcp.json` del tuo progetto:

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

Completa l’accesso a Brew tramite OAuth e seleziona il brand su cui vuoi lavorare. Chiedi all’agente di richiamare `get_brew_capabilities`. Se il tuo client usa un formato di configurazione diverso, segui la [guida alla configurazione dei client](https://docs.brew.new/api-reference/mcp/connect-your-client). Tieni le chiavi API fuori dalla chat e dal repository.

## Definisci separatamente l’idoneità per la registrazione e per il promemoria

Chiedi a Cursor di trovare il punto del codice in cui viene salvato definitivamente un nuovo account. Decidi cosa conta come attivazione, per esempio creare un primo progetto. Questa guida tiene i controlli di idoneità nell’applicazione e usa due trigger distinti:

- Un trigger di registrazione per il benvenuto immediato.
- Un trigger per il promemoria idoneo, che la tua applicazione attiva solo dopo aver verificato lo stato di attivazione attuale.

Usa `save_trigger` per definire ogni payload, compresa la stringa email obbligatoria. Salva gli ID dei trigger effettivamente restituiti. Un nome visualizzato come `user_signed_up` non sostituisce l’identificativo dell’API.

## Crea e rivedi le email

Un buon primo brief è questo:

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

L’agente può usare `create_email`, `edit_email` e `save_automation`. Apri i risultati in Brew e controlla layout, testi, link e dominio di invio. Usa la [sintassi dei merge tag](https://docs.brew.new/create-emails/merge-tags) indicata nella documentazione, con un valore di riserva testato per quando manca il nome.

Non mettere un filtro `activated is false` in un percorso lineare prima di un follow-up `activated is true`. Un filtro non superato blocca tutti i nodi che lo seguono. I campi dell’evento come `payload.activated` restano invariati dopo un’attesa. In alternativa a questa ricetta, in cui è l’applicazione a programmare i controlli, definisci e sincronizza un campo booleano del contatto e verifica `contact.activated` dopo ogni attesa rilevante. Quella condizione legge il contatto attuale in Brew, non il database della tua applicazione. Consulta la [guida alla sequenza per il periodo di prova](/it/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).

## Collega il backend

Recupera il contratto di ogni trigger con `get_trigger_contract`, oppure genera i contratti con la [CLI](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Attiva il trigger di registrazione dopo il commit della transazione che crea l’account.

Questo esempio per la shell presuppone che `BREW_SIGNUP_TRIGGER_ID` contenga l’identificativo restituito quando hai creato il trigger e che il suo schema dichiari `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"}}'
```

Usa una chiave stabile per ogni evento di registrazione, conservala per i nuovi tentativi e analizza le risposte di errore. Segui il [contratto di idempotenza dell’API](https://docs.brew.new/api-reference/api/idempotency).

Quando è il momento di inviare un promemoria, la tua applicazione legge l’account attuale. Se l’utente si è attivato, è stato eliminato o per altri motivi non è idoneo, non attiva il trigger del promemoria. Altrimenti invia un nuovo evento con i dati attuali. Un aggiornamento dei campi del contatto, da solo, non annulla l’esecuzione originale.

## Testa prima di pubblicare

Usa `test_automation` con destinatari controllati. Verifica il [comportamento attuale dei test](https://docs.brew.new/create-emails/build-an-automation) ed esamina la cronologia delle esecuzioni. Testa anche il pianificatore dell’applicazione:

1. Un nuovo account riceve il benvenuto una sola volta.
2. Un account non attivo produce un solo evento di promemoria idoneo.
3. Un account che si attiva prima del controllo programmato non produce alcun evento di promemoria.
4. Un nuovo tentativo non crea un invio in più.
5. I campi mancanti o non validi producono un errore che il tuo backend registra e gestisce.

Verifica la finalità del dominio di invio e i requisiti di consenso. Poi pubblica in modo esplicito con `save_automation` e `published: true`. Un’automazione pubblicata può essere eseguita su eventi reali.

Per progettare la sequenza nel suo insieme, consulta le [sequenze di email di benvenuto](/it/blog/welcome-email-sequence). Per scegliere l’interfaccia che usa il tuo backend, consulta [MCP o API REST](/it/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use).