Connecter Postmark à n8n : emails transactionnels, Message Streams et webhooks de bounce

Un email transactionnel raté — confirmation de commande, réinitialisation de mot de passe, facture — coûte plus cher qu'un email marketing raté : le client ne relance pas une newsletter manquante, mais il contacte le support quand sa facture n'arrive jamais. Postmark s'est construit une réputation sur ce point précis : délivrabilité maximale pour le transactionnel, séparation stricte d'avec le marketing via les Message Streams, et des webhooks qui remontent chaque bounce en quelques secondes. Coupler cette rigueur à un workflow n8n permet de fermer la boucle automatiquement — un email qui échoue déclenche une action, pas un silence.

Ce que n8n propose nativement (et ce qu'il faut construire soi-même)

n8n intègre un node Postmark Trigger, qui reçoit les webhooks entrants de Postmark (bounce, ouverture, clic, spam complaint, email inbound). Pour la réception d'événements, aucune configuration HTTP manuelle n'est nécessaire : le node génère son URL de webhook et gère l'abonnement.

En revanche, il n'existe pas de node d'action Postmark dédié pour l'envoi. L'envoi d'un email passe par un node HTTP Request classique, exactement comme décrit dans notre guide du node HTTP Request pour piloter une API REST — une limite qui rejoint celle rencontrée avec Resend, où l'API est elle aussi appelée en HTTP Request brut plutôt que via un node dédié.

Vérifier un expéditeur avant le premier envoi

Postmark refuse tout envoi tant que l'adresse From n'est pas rattachée à une sender signature confirmée (adresse unique validée par email de confirmation) ou à un domaine vérifié (DNS : SPF, DKIM, et Return-Path pour le suivi des bounces). Sans cette étape, chaque appel API renvoie une erreur 422 — contrairement à certaines API concurrentes qui tolèrent un envoi de test non vérifié depuis un domaine partagé.

Cette rigueur sur l'authentification n'est pas arbitraire. Une étude de Tatang, Zettl et Holz, présentée à la conférence RAID 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 dans son ensemble et que les domaines correctement couverts par les trois protocoles réduisent nettement leur exposition au spoofing et au classement en spam. Exiger la vérification avant tout envoi, comme le fait Postmark, revient à imposer ce socle plutôt que de le laisser à la discrétion de chaque expéditeur.

Une fois le domaine ajouté et les enregistrements DNS collés chez le registrar, le statut passe à Verified dans le tableau de bord Postmark (onglet Sender Signatures ou Domains) — généralement en quelques minutes, le temps de propagation DNS.

Envoyer un email avec le node HTTP Request

Le node HTTP Request appelle l'API Postmark avec cette configuration :

• Méthode : POST
• URL : https://api.postmarkapp.com/email
• Authentification : credential Header Auth, en-tête X-Postmark-Server-Token, valeur le Server API Token (récupéré dans l'onglet API Tokens du serveur Postmark concerné)
• Corps JSON : From (adresse vérifiée), To, Subject, HtmlBody et/ou TextBody, et optionnellement MessageStream (voir plus bas)

Pour tester sans risque d'envoi réel, remplacer le Server API Token par la valeur littérale POSTMARK_API_TEST : Postmark répond normalement (structure de réponse identique) mais ne délivre rien — utile pour valider un workflow avant de brancher le vrai token en production, sur le même principe que le mode test décrit dans notre guide sur les webhooks Stripe.

Pour des emails avec pièces jointes (facture PDF, export CSV), le champ Attachments accepte un tableau d'objets avec Name, Content (encodé en base64) et ContentType — un contenu généré en amont par un PDF de facture créé dans le même workflow ou récupéré via le node Convert to File.

Séparer transactionnel et marketing avec les Message Streams

Un Message Stream est un canal d'envoi isolé, avec sa propre réputation de délivrabilité, ses propres statistiques et ses propres webhooks. Chaque serveur Postmark dispose d'un stream outbound par défaut, dédié au transactionnel, et peut ajouter un stream de type broadcast pour les envois marketing ou les newsletters.

Cette séparation compte concrètement : un pic d'envoi marketing (newsletter, campagne promotionnelle) qui dégrade la réputation d'un domaine ne doit jamais entraîner la mise en spam d'un email de réinitialisation de mot de passe. En précisant MessageStream dans le corps de la requête HTTP Request (par exemple "outbound" pour le transactionnel), le workflow n8n garde cette frontière — utile si le même site envoie aussi une newsletter automatique générée depuis un flux RSS : les deux usages ne doivent jamais partager le même stream.

Réagir aux bounces avec le Postmark Trigger

Le node Postmark Trigger reçoit les événements configurés dans l'onglet Webhooks d'un stream Postmark : Bounce, Open, Click, SpamComplaint, Delivery, ou InboundMail selon le type de stream. Chaque événement Bounce distingue en particulier le HardBounce (adresse invalide, définitive) du SoftBounce (boîte pleine, serveur temporairement indisponible) — une distinction que le workflow doit traiter différemment :

1. Le node Postmark Trigger reçoit l'événement Bounce.
2. Un node IF ou Switch (voir notre guide du routage conditionnel) sépare HardBounce des autres types.
3. Sur un HardBounce, l'adresse est marquée invalide dans le CRM ou la base — le même réflexe que celui décrit dans notre guide sur les relances automatiques, où toute relance doit d'abord vérifier que le canal de contact reste valide avant d'insister.
4. Sur les autres cas, le workflow peut se contenter de journaliser l'événement ou d'alerter l'équipe support via un bot Slack au-delà d'un certain seuil.

Un cas concret : facture envoyée, suivie, et relancée si nécessaire

Un scénario complet illustre l'intérêt de coupler API et webhook plutôt que d'envoyer un email « à l'aveugle » :

1. Un workflow de facturation génère la facture PDF et déclenche l'envoi via POST /email, en conservant le MessageID renvoyé par Postmark aux côtés du numéro de facture dans une table Supabase (voir notre guide de connexion Supabase).
2. Le Postmark Trigger écoute les événements Delivery et Bounce du stream, et met à jour cette même table dès qu'un statut change.
3. Si aucun événement Delivery n'arrive dans un délai raisonnable et qu'un HardBounce est reçu à la place, un second workflow programmé (voir notre guide du Schedule Trigger) relance la facture par un canal alternatif — SMS via Twilio ou message direct sur un CRM déjà connecté.

Ce pattern — envoyer, tracer via webhook, escalader sur échec — transforme un envoi d'email d'une action ponctuelle et silencieuse en un processus dont on connaît toujours l'issue, sans jamais avoir à demander au client s'il a bien reçu son document.

---

Pour aller plus loin : les workflows d'automatisation email et de facturation du Pack Conformité & Audit et du Pack Assistant RAG intègrent déjà ces patterns de traçabilité prêts à adapter à votre stack.