# Como criar uma sequência de e-mails de onboarding pelo Cursor

URL canônica: https://brew.new/pt-br/blog/how-to-create-an-email-onboarding-sequence-from-cursor
Por Philip Sørensen
Publicado em 2026-09-25
Atualizado em 2026-09-29

Um e-mail de onboarding depende dos mesmos dados de eventos que o seu produto. Trabalhar pelo Cursor permite revisar o handler de cadastro, criar o gatilho correspondente no Brew e conferir o e-mail em um só lugar. Mantenha uma pessoa responsável por publicar o fluxo e aprovar os envios reais.

## Conecte o Brew

Adicione este servidor nas configurações de MCP do Cursor ou no `.cursor/mcp.json` do seu projeto:

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

Conclua o login OAuth do Brew e selecione a marca certa. Peça ao agente que chame `get_brew_capabilities`. Siga o [guia de configuração de clientes](https://docs.brew.new/api-reference/mcp/connect-your-client) se o seu cliente MCP usar outro formato de configuração. Mantenha as chaves de API fora do chat e do repositório.

## Defina separadamente o cadastro e a elegibilidade para o lembrete

Peça ao Cursor que localize o código que efetiva a criação de uma conta nova. Decida o que conta como ativação, como criar o primeiro projeto. Este passo a passo mantém as verificações de elegibilidade na aplicação e usa dois gatilhos diferentes:

- Um gatilho de cadastro para as boas-vindas imediatas.
- Um gatilho de lembrete elegível, que a sua aplicação só dispara depois de verificar o estado atual de ativação.

Use `save_trigger` para definir cada payload, incluindo a string obrigatória de e-mail. Guarde os IDs de gatilho que forem realmente retornados. Um nome de exibição como `user_signed_up` não substitui o identificador da API.

## Monte e revise os e-mails

Um primeiro briefing útil:

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

O agente pode usar `create_email`, `edit_email` e `save_automation`. Abra os resultados no Brew e confira o layout, o texto, os links e o domínio de envio. Use a [sintaxe de tags de mesclagem](https://docs.brew.new/create-emails/merge-tags) documentada, incluindo um valor padrão testado para quando faltar o nome.

Não coloque um filtro `activated is false` num caminho linear antes de um e-mail seguinte com `activated is true`. Quando o filtro não passa, nenhuma das etapas que vêm depois dele é executada. Campos do evento como `payload.activated` continuam fixos depois de uma espera. Como alternativa a este roteiro agendado pela aplicação, defina e sincronize um campo de contato booleano e verifique `contact.activated` depois de cada espera relevante. Essa condição lê o contato atual no Brew, não o banco de dados da sua aplicação. Veja o [guia da sequência de conversão de períodos de teste](/pt-br/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).

## Conecte o back-end

Busque o contrato de cada gatilho com `get_trigger_contract` ou gere os contratos com a [CLI](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Dispare o gatilho de cadastro depois que a transação de criação da conta for confirmada (commit).

Este exemplo em shell supõe que `BREW_SIGNUP_TRIGGER_ID` contém o identificador retornado quando você criou o gatilho e que o esquema dele declara `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"}}'
```

Use uma chave estável por evento de cadastro, mantenha a mesma chave nas novas tentativas e analise as respostas com falha. Siga o [contrato de idempotência da API](https://docs.brew.new/api-reference/api/idempotency).

Quando chega a hora de um lembrete, a sua aplicação lê o estado atual da conta. Se o usuário já ativou, foi excluído ou não é elegível por outro motivo, ela não dispara o gatilho de lembrete. Caso contrário, envia um novo evento com os dados atuais. Atualizar um campo do contato, por si só, não cancela a execução original.

## Teste antes de publicar

Use `test_automation` com destinatários controlados. Confira o [comportamento atual dos testes](https://docs.brew.new/create-emails/build-an-automation) e analise o histórico de execuções. Teste também o agendador da aplicação:

1. Uma conta nova recebe as boas-vindas uma única vez.
2. Uma conta inativa gera um evento de lembrete elegível.
3. Uma conta ativada antes da verificação agendada não gera nenhum evento de lembrete.
4. Uma nova tentativa não cria um envio a mais.
5. Campos ausentes ou inválidos geram um erro que o seu back-end registra e trata.

Revise a finalidade do domínio de envio e os requisitos de consentimento. Depois, publique de forma explícita com `save_automation` e `published: true`. Uma automação publicada pode ser executada a partir de eventos reais.

Para o desenho da sequência como um todo, veja [sequências de e-mails de boas-vindas](/pt-br/blog/welcome-email-sequence). Para escolher a interface que o seu back-end usa, veja [MCP vs REST](/pt-br/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use).