Un e-mail d’onboarding dépend des mêmes données d’événement que votre produit. Travailler depuis Cursor vous permet de relire le gestionnaire d’inscription, de créer le déclencheur Brew correspondant et de vérifier l’e-mail au même endroit. Confiez à une personne la responsabilité de publier la séquence et de valider les envois réels.

Connectez Brew

Ajoutez ce serveur dans les paramètres MCP de Cursor ou dans le fichier .cursor/mcp.json de votre projet :

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

Terminez la connexion OAuth de Brew et sélectionnez la marque voulue. Demandez à l’agent d’appeler get_brew_capabilities. Suivez le guide de configuration des clients si votre client utilise un autre format de configuration. Ne mettez aucune clé API dans la conversation ni dans le dépôt.

Définissez séparément l’inscription et l’éligibilité aux rappels

Demandez à Cursor de trouver le code qui enregistre un nouveau compte en base. Décidez de ce qui compte comme une activation, par exemple la création d’un premier projet. Ce tutoriel laisse les vérifications d’éligibilité dans l’application et utilise deux déclencheurs distincts :

• Un déclencheur d’inscription, pour l’e-mail de bienvenue immédiat.
• Un déclencheur de rappel éligible, que votre application n’actionne qu’après avoir vérifié l’état d’activation actuel.

Utilisez save_trigger pour définir chaque payload, y compris le champ email obligatoire, de type chaîne. Enregistrez les identifiants de déclencheur réellement renvoyés. Un nom d’affichage comme user_signed_up ne remplace pas l’identifiant d’API.

Créez et relisez les e-mails

Voici un premier brief utile :

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’agent peut utiliser create_email, edit_email et save_automation. Ouvrez les résultats dans Brew et vérifiez la mise en page, les textes, les liens et le domaine d’envoi. Utilisez la syntaxe des balises de fusion documentée, avec une valeur par défaut testée pour un nom manquant.

Ne placez pas un filtre activated is false sur un chemin linéaire avant une relance activated is true : un filtre non satisfait arrête toutes les étapes qui en descendent. Les champs de l’événement comme payload.activated restent figés après une attente. Plutôt que cette méthode, où l’application planifie les rappels, vous pouvez définir et synchroniser un champ de contact booléen, puis vérifier contact.activated après chaque attente concernée. Cette condition lit le contact Brew actuel, pas la base de données de votre application. Consultez le guide de la séquence d’essai.

Branchez le backend

Récupérez le contrat de chaque déclencheur avec get_trigger_contract, ou générez les contrats avec la CLI. Actionnez le déclencheur d’inscription une fois la transaction de création du compte validée.

Cet exemple shell suppose que BREW_SIGNUP_TRIGGER_ID contient l’identifiant renvoyé à la création du déclencheur, et que son schéma déclare 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"}}'

Utilisez une clé stable par événement d’inscription, conservez-la pour les nouvelles tentatives et examinez les réponses en échec. Suivez le contrat d’idempotence de l’API.

Quand un rappel arrive à échéance, votre application lit l’état actuel du compte. Si l’utilisateur est activé, supprimé ou inéligible pour une autre raison, elle n’actionne pas le déclencheur de rappel. Sinon, elle envoie un nouvel événement avec les données actuelles. La mise à jour d’un champ de contact ne suffit pas, à elle seule, à annuler l’exécution d’origine.

Testez avant de publier

Utilisez test_automation avec des destinataires maîtrisés. Vérifiez le comportement actuel des tests et examinez l’historique des exécutions. Testez aussi le planificateur de l’application :

1. Un nouveau compte reçoit l’e-mail de bienvenue une seule fois.
2. Un compte inactif produit un seul événement de rappel éligible.
3. Un compte activé avant la vérification planifiée ne produit aucun événement de rappel.
4. Une nouvelle tentative ne crée pas d’envoi supplémentaire.
5. Des champs manquants ou non valides produisent une erreur que votre backend enregistre et traite.

Vérifiez l’usage d’envoi du domaine et les exigences de consentement. Publiez ensuite explicitement avec save_automation et published: true. Une automatisation publiée peut s’exécuter sur des événements réels.

Pour concevoir la séquence dans son ensemble, consultez notre guide de la séquence de bienvenue. Pour choisir l’interface qu’utilise votre backend, lisez MCP ou REST.