Resend ou Mailgun pour l’API email de votre SaaS ?

Pour une équipe SaaS qui veut envoyer des confirmations, alertes et messages liés au compte depuis son application, Resend et Mailgun proposent deux API transactionnelles avec des tarifs calculés par volume. Resend convient à une intégration qui commence avec un quota gratuit de 3 000 emails par mois, plafonné aussi à 100 par jour. Mailgun donne accès à des outils complémentaires comme la validation d’adresses et le routage entrant. À 50 000 emails par mois, Resend Pro coûte 20 $ par mois et Mailgun Foundation coûte 35 $ par mois après le premier mois. À 100 000 emails par mois, Resend Pro coûte 35 $ et Resend Scale 90 $ par mois, tandis que Mailgun Scale coûte 90 $ après le premier mois. Ces paliers répondent à des besoins différents : il faut comparer le volume, les journaux nécessaires et les opérations que votre équipe souhaite gérer.

Resend et Mailgun en un coup d’œil

Comparer les plans gratuits et les quotas

Les deux offres gratuites reposent sur une limite journalière de 100 emails. Resend ajoute un plafond mensuel de 3 000 emails et autorise trois domaines. Mailgun Free comprend un domaine d’envoi personnalisé et conserve les journaux pendant une journée. Cette distinction compte dès les essais d’intégration : un SaaS peut envoyer peu de messages en moyenne, mais générer des pointes lorsqu’une action déclenche plusieurs notifications. Le plafond par jour reste alors pertinent même si le total du mois demeure modeste.

Pour évaluer ces limites, estimez séparément les emails de bienvenue, les reçus, les changements de mot de passe, les alertes de compte et les notifications produit. Ajoutez une marge pour les tentatives d’envoi répétées et les périodes de forte activité, sans confondre les envois prévus avec le nombre de contacts de votre base. Le quota de Resend se compte en emails par mois avec une borne journalière. Mailgun Free se présente avec un volume journalier ; le plan n’annonce pas dans les faits consultés un quota mensuel gratuit à comparer directement.

Le nombre de domaines mérite aussi une vérification en fonction de l’architecture de votre produit. Resend Free inclut trois domaines ; Mailgun Free en inclut un pour l’envoi personnalisé. Une équipe qui sépare les messages de plusieurs produits, environnements ou marques peut donc tenir compte de cette différence avant de déplacer son trafic. Les domaines de test et de production doivent être pensés avec le DNS et les responsabilités de l’équipe, plutôt qu’ajoutés au dernier moment.

Prix à 50 000 et à 100 000 emails par mois

À 50 000 emails mensuels, Resend Pro coûte 20 $ par mois pour ce volume. Le palier Mailgun Foundation comprend également 50 000 emails par mois et coûte 35 $ par mois après le premier mois. Foundation inclut cinq jours de rétention des journaux et son dépassement commence à 1,30 $ par tranche de 1 000 emails. Resend Pro facture les emails supplémentaires à 0,90 $ par tranche de 1 000. Ces prix se lisent plan par plan : le coût réel dépend notamment de la régularité des volumes et de la nécessité de consulter l’historique après un incident.

À 100 000 emails mensuels, Resend Pro coûte 35 $ par mois et Scale coûte 90 $ par mois. L’offre Scale de Mailgun coûte 90 $ par mois après le premier mois pour 100 000 emails. Il ne faut pas confondre les deux offres Resend : elles correspondent à des plans différents au même volume. Scale de Mailgun inclut 30 jours de rétention des journaux et 5 000 validations. Resend facture les volumes supplémentaires à 0,90 $ par 1 000 emails en Pro et Scale.

Pour un volume supérieur au quota, la différence de prix unitaire ne suffit pas à choisir. Relevez le nombre d’emails excédentaires sur plusieurs périodes et observez leur origine : hausse durable du trafic, pic ponctuel ou défaut de logique qui relance inutilement un message. Les tarifs de dépassement de Mailgun varient selon le plan : Basic commence à 1,80 $ par 1 000 emails et Foundation à 1,30 $. Resend Pro et Scale facturent 0,90 $ par 1 000 emails supplémentaires. Les validations d’adresses ont aussi une tarification distincte chez Mailgun ; elles ne sont pas des emails envoyés et ne doivent pas être ajoutées au volume de livraison.

Journaux, validations et messages entrants

La durée de conservation des journaux peut changer la manière dont l’équipe enquête sur un message absent ou une erreur de traitement. Mailgun garde les journaux pendant une journée sur Free et Basic, cinq jours sur Foundation, et trente jours sur Scale. Si les équipes de support et d’ingénierie ont besoin de retracer un incident après plusieurs jours, les paliers Foundation et Scale ont des durées différentes à intégrer dans le choix. Avant de migrer vers Resend, vérifiez la durée de rétention des journaux dans votre compte.

Mailgun ajoute des validations d’adresses email. Scale inclut 5 000 validations ; des validations supplémentaires sont tarifées séparément. Une validation peut aider une application qui accepte des adresses dans ses formulaires ou qui doit traiter des listes avant l’envoi. Définissez la fréquence à laquelle votre système en aura besoin, et distinguez cette opération de la livraison transactionnelle. L’intérêt dépend de votre flux de données et des règles de collecte que vous avez déjà mises en place.

Le routage entrant de Mailgun concerne les messages reçus et dirigés vers un traitement, alors que l’API d’envoi gère les notifications sortantes. Cela peut compter si votre produit traite les réponses reçues à une adresse dédiée. Cartographiez le parcours : adresse de réception, destination ou traitement applicatif, puis conservation éventuelle du contenu. Si le besoin se limite à envoyer des reçus et des alertes sans exploiter les réponses, cette fonction peut ne pas peser dans la décision.

Mailgun propose aussi des IP dédiées, des analyses de délivrabilité, SAML SSO et des régions d’hébergement aux États-Unis et dans l’Union européenne. Ces capacités s’adressent à des contraintes d’exploitation ou d’organisation précises. Vérifiez quel plan ou quelles conditions s’appliquent à la fonction voulue et confrontez-les à vos obligations internes. Aucune région d’hébergement équivalente n’est établie ici pour Resend, donc ce critère doit être examiné directement avec les deux fournisseurs si votre architecture l’exige.

Expérience de développement et intégration

Pour une API email, l’expérience de développement se juge dans le contexte de votre application : comment l’équipe déclenche un envoi, gère les erreurs, suit les réponses et maintient les modèles. Les deux services ciblent les usages transactionnels et exposent une API ; Mailgun propose également un relais SMTP. Si votre code existant envoie déjà par SMTP, ce mode peut s’insérer dans le chemin d’intégration que vous connaissez. Avec une intégration orientée API, comparez les bibliothèques et les exemples destinés à votre langage avant de prendre une décision technique.

Ne fondez pas le choix sur une impression générale de simplicité. Prenez un scénario réel du produit, comme l’envoi d’un reçu après paiement, et tracez les étapes : appel depuis le serveur, configuration des identifiants, réponse en cas de refus et visibilité côté équipe. Vérifiez les SDK nécessaires à la pile que vous utilisez ainsi que la manière d’exploiter les événements ou journaux dans votre système. Les informations considérées pour cette page ne permettent pas d’établir une différence précise entre leurs SDK ; le bon contrôle consiste donc à tester le parcours de votre application avec chaque intégration candidate.

Gardez les identifiants côté serveur et séparez les environnements de développement et de production dans votre configuration. Créez une couche d’envoi interne qui reçoit un type de message et ses données, plutôt que de disperser les appels au fournisseur dans plusieurs parties du produit. Cette organisation clarifie les changements de fournisseur, les journaux applicatifs et le traitement des erreurs. Elle ne supprime pas le travail de migration, mais limite le nombre de points qui dépendent directement d’une API particulière.

L’onglet marketing de Resend est un produit distinct

Resend distingue l’envoi transactionnel de son onglet marketing. Les plans marketing sont calculés par contacts, et non selon le même repère que les plans transactionnels par emails envoyés. L’offre Marketing Free est gratuite jusqu’à 1 000 contacts. Le plan Pro marketing coûte 40 $ par mois à 5 000 contacts. Ces repères ne remplacent pas le tarif Pro transactionnel à 50 000 emails ; ils décrivent un autre périmètre et une autre unité de volume.

Une équipe qui souhaite des campagnes périodiques en plus des courriels déclenchés par l’application doit donc prévoir les deux usages séparément. Les messages de réinitialisation de mot de passe suivent un événement du produit, alors qu’une annonce envoyée à une liste relève du marketing. Séparer les estimations évite de traiter un nombre de contacts comme s’il représentait le même volume que les transactions. Mailgun centre son offre sur l’envoi transactionnel et les opérations associées.

Quand envisager Resend ou Mailgun

Si votre priorité est seulement d’envoyer des emails liés aux événements du produit, comparez d’abord le volume attendu, les limites du plan choisi et le comportement de l’intégration dans votre pile. Si l’équipe doit valider des adresses, recevoir des emails dans le produit ou conserver un historique plus long, les fonctions Mailgun donnent des critères supplémentaires à évaluer. Le plan retenu doit correspondre à un besoin concret : ne payez pas pour une durée de journal ou une fonction d’exploitation qui n’a pas de responsable ni de cas d’usage.

Préparer la migration et la configuration DNS

Le changement de fournisseur touche à la fois le code et l’identité d’envoi. Commencez par inventorier les catégories de messages, leurs déclencheurs, les modèles, les destinataires et les systèmes qui appellent l’API ou le relais SMTP. Repérez également les alertes de livraison et les processus qui dépendent de journaux. Cet inventaire permet de planifier la migration par famille de messages plutôt que de basculer toute l’application en une seule opération.

Ensuite, configurez le domaine d’envoi dans le compte retenu et appliquez les enregistrements DNS demandés par le fournisseur. Vérifiez la configuration avant de diriger le trafic de production vers le nouveau service. Les changements DNS peuvent prendre du temps à se propager ; gardez une fenêtre où l’équipe peut contrôler les envois et les erreurs. N’effacez pas la configuration existante tant que les messages importants ne passent pas par le nouveau chemin et que les alertes ne sont pas comprises.

Pour réduire les risques, déplacez un petit groupe de notifications, examinez les résultats et élargissez progressivement le périmètre. Comparez les identifiants de message, les réponses d’API, les erreurs et les événements que votre application enregistre. Conservez les modèles et la logique de déclenchement dans votre dépôt afin que les changements restent révisables. Une migration bien préparée inclut un retour possible à l’ancien chemin pendant la période de transition, avec une personne responsable de la décision de bascule.

Questions fréquentes