Connecter Resend à n8n : envoyer des emails transactionnels et suivre leur statut par webhook

Le node Send Email de n8n fonctionne en SMTP : il suffit d'un serveur et d'identifiants, mais il ne dit rien du sort de l'email une fois parti — livré, rebondi, marqué comme spam ? Le silence total, jusqu'à ce qu'un client signale ne rien avoir reçu. Resend prend le problème à l'envers : une API REST simple pour l'envoi, doublée d'webhooks qui notifient n8n à chaque changement de statut. De quoi construire un pipeline d'emails transactionnels (confirmation de commande, facture, réinitialisation de mot de passe, alerte) qui sait ce qu'il devient, plutôt que d'espérer qu'il arrive.

Générer une clé API et vérifier un domaine

Un compte Resend gratuit suffit pour démarrer : le tableau de bord propose de créer une API Key en quelques secondes, préfixée re_. Pour tester, un envoi depuis le domaine partagé onboarding@resend.dev fonctionne sans configuration — pratique pour valider un workflow avant de le brancher en production.

Pour un usage réel, vérifier votre propre domaine est indispensable : dans Domains, ajoutez le domaine d'envoi et collez les enregistrements DNS fournis (un enregistrement SPF, une clé DKIM, et un enregistrement DMARC recommandé) chez votre registrar. Cette étape n'est pas une formalité — une étude de Tatang, Zettl et Holz, publiée à la conférence RAID en 2021 (« The Evolution of DNS-based Email Authentication: Measuring Adoption and Finding Flaws », voir sur Google Scholar), montre que l'adoption de SPF, DKIM et DMARC reste très inégale sur le web et que les domaines correctement configurés sur les trois protocoles sont nettement moins exposés au spoofing et au classement en spam par les filtres des grands fournisseurs de messagerie. Sans ces enregistrements, même un contenu d'email irréprochable finit souvent en indésirables.

Envoyer un email depuis n8n

Une fois le domaine vérifié, l'envoi se fait avec un seul node HTTP Request :

• Méthode : POST
• URL : https://api.resend.com/emails
• Authentification : credential Header Auth, en-tête Authorization, valeur Bearer re_votre_cle_api
• Corps JSON : from (une adresse de votre domaine vérifié, avec nom facultatif : "Boutique <commandes@votredomaine.com>"), to, subject, et html (ou text) pour le contenu

Aucun node communautaire n'est nécessaire — l'API Resend est volontairement minimaliste et un HTTP Request brut, comme détaillé dans notre guide du node HTTP Request pour piloter une API REST, suffit à couvrir l'essentiel. Pour des emails plus élaborés (facture PDF en pièce jointe, relance de panier), le champ attachments accepte un contenu encodé en base64, généré en amont par un node Code ou récupéré d'un PDF de facture généré dans le même workflow.

Contrairement au node Send Email en SMTP, comparé en détail dans notre guide dédié à l'envoi via SMTP, l'API Resend renvoie immédiatement un identifiant d'email (id) dans la réponse — à conserver pour recouper plus tard chaque événement de webhook avec l'envoi d'origine.

Un cas d'usage concret : confirmation de commande avec suivi

Un scénario e-commerce illustre bien l'intérêt du couple API + webhook. Le workflow décrit dans notre guide sur l'automatisation des commandes e-commerce déclenche un email de confirmation dès qu'une commande Shopify ou WooCommerce est créée. Avec Resend :

1. Le Webhook Trigger Shopify (voir notre guide de connexion Shopify) reçoit la nouvelle commande.
2. Un node HTTP Request appelle POST /emails avec les détails de la commande, et stocke l'id retourné dans une table Supabase, aux côtés du numéro de commande.
3. Un second Webhook Trigger, cette fois côté Resend, écoute les événements email.delivered, email.bounced et email.complained, et met à jour le statut de l'envoi dans cette même table.
4. Sur un email.bounced, un node Slack alerte l'équipe support — l'adresse email du client est probablement fausse, et la commande risque de rester sans confirmation reçue.

Ce même schéma se transpose directement aux relances de paiement décrites dans notre guide sur les webhooks Stripe et relances : un email de relance parti « dans le vide » sans qu'on le sache est pire qu'une absence d'automatisation.

Configurer et sécuriser le webhook Resend

Dans le tableau de bord Resend, la section Webhooks permet d'ajouter l'URL de production de votre Webhook Trigger n8n et de sélectionner les événements à recevoir (email.sent, email.delivered, email.delivery_delayed, email.bounced, email.complained, email.opened, email.clicked). Chaque requête est signée par Svix, l'infrastructure de webhooks utilisée par Resend : trois en-têtes (svix-id, svix-timestamp, svix-signature) accompagnent chaque payload, et la signature est un HMAC-SHA256 calculé sur l'identifiant, l'horodatage et le corps brut concaténés. Vérifier cette signature avant de traiter l'événement — plutôt que de faire confiance à n'importe quelle requête arrivant sur l'URL publique — suit exactement la méthode décrite dans notre guide de sécurisation des webhooks n8n, avec un node Crypto pour recalculer le HMAC (voir aussi notre guide du node Crypto) et le comparer à l'en-tête reçu.

Comme tout webhook, des livraisons dupliquées peuvent survenir en cas de nouvelle tentative côté Resend : un mécanisme d'idempotence basé sur svix-id, détaillé dans notre guide dédié, évite de traiter deux fois le même événement et d'envoyer une seconde alerte pour un même rebond.

Resend n'est pas un outil d'emailing marketing

Il vaut mieux clarifier ce distinguo avant de mal choisir son outil : Resend est conçu pour l'email transactionnel, déclenché par une action utilisateur (inscription, commande, facture, réinitialisation de mot de passe), pas pour des campagnes de masse. Pour des newsletters ou des séquences marketing envoyées à une liste de contacts, notre guide sur l'automatisation de l'email marketing avec Brevo reste la référence adaptée — Brevo gère consentement, désabonnement et segmentation, ce que l'API Resend ne fait pas nativement. Mélanger les deux usages sur un même domaine dégrade en général la délivrabilité de l'ensemble : un domaine ou un sous-domaine dédié par type d'envoi limite ce risque.

Sécuriser la clé API

La clé Resend permet d'envoyer des emails au nom de votre domaine — un accès qui, entre de mauvaises mains, sert aussi bien au spam qu'au phishing ciblé usurpant votre marque. Stockez-la exclusivement dans un credential n8n chiffré, jamais dans un node Set ou une variable partagée, en suivant les principes détaillés dans notre guide de sécurisation des credentials API. Le tableau de bord Resend permet de créer des clés à portée restreinte (envoi uniquement, sans accès à la gestion des domaines ou des webhooks) : limiter chaque credential n8n à la portée strictement nécessaire réduit l'impact d'une fuite éventuelle.

Pour aller plus loin

Ce pipeline transforme un envoi d'email « à l'aveugle » en un flux dont chaque étape est tracée, du déclenchement au statut final. Si ce suivi doit alimenter une piste d'audit complète (qui a reçu quoi, quand, avec quel statut de livraison), le Pack Conformité & Audit (149 €) fournit la brique de journalisation Supabase prête à brancher en sortie des webhooks Resend. Et si vos emails transactionnels s'insèrent dans un flux plus large de tri et de réponse automatique des emails entrants, le Pack Inbox IA (79 €) couvre l'autre moitié du parcours. Les trois packs, réunis dans le Bundle FlowKit Complet (269 € au lieu de 347 € pris séparément), couvrent l'ensemble du cycle de vie d'un email, de sa réception à la confirmation de sa livraison.