# Cómo crear una secuencia de emails de onboarding desde Cursor

URL canónica: https://brew.new/es/blog/how-to-create-an-email-onboarding-sequence-from-cursor
Autoría: Philip Sørensen
Publicado: 2026-09-25
Actualizado: 2026-09-29

Un email de onboarding depende de los mismos datos de eventos que tu producto. Trabajar desde Cursor te permite revisar el código que gestiona los registros, crear el disparador de Brew correspondiente y comprobar el email en un mismo lugar. Deja en manos de una persona la publicación del flujo y la aprobación de los envíos reales.

## Conecta Brew

Añade este servidor en la configuración de MCP de Cursor o en el archivo `.cursor/mcp.json` de tu proyecto:

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

Completa el inicio de sesión OAuth de Brew y selecciona la marca que corresponda. Pide al agente que llame a `get_brew_capabilities`. Si tu cliente usa otro formato de configuración, sigue la [guía de configuración de clientes](https://docs.brew.new/api-reference/mcp/connect-your-client). No pongas claves de API en el chat ni en el repositorio.

## Define por separado los requisitos del registro y del recordatorio

Pide a Cursor que localice el código que guarda una cuenta nueva en la base de datos. Decide qué cuenta como activación, por ejemplo, crear un primer proyecto. Esta guía deja las comprobaciones de requisitos en la aplicación y usa dos disparadores distintos:

- Un disparador de registro para la bienvenida inmediata.
- Un disparador de recordatorio para quienes cumplen los requisitos, que tu aplicación solo activa después de comprobar el estado actual de activación.

Usa `save_trigger` para definir cada payload, incluida la cadena obligatoria del email. Guarda los ID de disparador que se devuelvan realmente. Un nombre visible como `user_signed_up` no sustituye al identificador de la API.

## Crea y revisa los emails

Este es un primer brief ú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.
```

El agente puede usar `create_email`, `edit_email` y `save_automation`. Abre los resultados en Brew y revisa la maquetación, los textos, los enlaces y el dominio de envío. Usa la [sintaxis de etiquetas de combinación](https://docs.brew.new/create-emails/merge-tags) documentada, con un valor predeterminado probado para cuando falte el nombre.

No pongas un filtro `activated is false` en una ruta lineal antes de un seguimiento con `activated is true`. Un filtro que no se cumple detiene todos los nodos que vienen después. Los campos del evento, como `payload.activated`, no cambian después de una espera. Como alternativa a esta receta programada desde la aplicación, define y sincroniza un campo booleano del contacto y comprueba `contact.activated` después de cada espera relevante. Esa condición lee el contacto actual en Brew, no la base de datos de tu aplicación. Consulta la [guía de secuencias para convertir pruebas gratuitas](/es/blog/how-to-build-a-saas-trial-conversion-email-sequence-with-product-events).

## Conecta el backend

Obtén el contrato de cada disparador con `get_trigger_contract` o genera los contratos con la [CLI](https://docs.brew.new/api-reference/guides/typed-payload-contracts). Activa el disparador de registro después de que se confirme la transacción que crea la cuenta.

Este ejemplo de shell da por hecho que `BREW_SIGNUP_TRIGGER_ID` contiene el identificador que se devolvió al crear el disparador y que su esquema 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"}}'
```

Usa una clave estable por cada evento de registro, consérvala para los reintentos y revisa las respuestas con error. Sigue el [contrato de idempotencia de la API](https://docs.brew.new/api-reference/api/idempotency).

Cuando toca enviar un recordatorio, tu aplicación lee el estado actual de la cuenta. Si el usuario ya se activó, se eliminó o por cualquier otro motivo no cumple los requisitos, la aplicación no activa el disparador del recordatorio. Si los cumple, envía un evento nuevo con los datos actuales. Actualizar un campo del contacto no basta para cancelar la ejecución original.

## Prueba antes de publicar

Usa `test_automation` con destinatarios controlados. Consulta [cómo funcionan ahora las pruebas](https://docs.brew.new/create-emails/build-an-automation) y revisa el historial de ejecuciones. Prueba también el programador de tareas de la aplicación:

1. Una cuenta nueva recibe la bienvenida una sola vez.
2. Una cuenta inactiva genera un único evento de recordatorio para quien cumple los requisitos.
3. Una cuenta que se activa antes de la comprobación programada no genera ningún evento de recordatorio.
4. Un reintento no genera un envío de más.
5. Los campos que faltan o no son válidos producen un error que tu backend registra y gestiona.

Revisa el propósito del dominio de envío y los requisitos de consentimiento. Después, publica de forma explícita con `save_automation` y `published: true`. Una automatización publicada puede ejecutarse con eventos reales.

Para el diseño general de la secuencia, consulta [secuencias de emails de bienvenida](/es/blog/welcome-email-sequence). Para elegir la interfaz que usa tu backend, consulta [MCP frente a REST](/es/blog/mcp-vs-rest-api-for-email-marketing-which-workflow-should-you-use).