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:

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

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

Conecte o back-end

Busque o contrato de cada gatilho com get_trigger_contract ou gere os contratos com a CLI. 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:

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.

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 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. Para escolher a interface que o seu back-end usa, veja MCP vs REST.