API e-mail compatibles Resend : ce que la compatibilité ne couvre pas

Ce que signifie réellement la compatibilité d’API

For email developers, Resend-compatible mail APIs implement the same request and response schemas as the provider they replace. If you use a Resend-compatible API, you can change your base URL and API key in your environment variables and your POST /emails calls will still work. It covers the syntax of the payload, the HTTP status codes, and the structure of the JSON response. It does not cover your sender reputation, your DNS configuration, your IP warm up, or your billing structure.

En tant qu’ingénieur qui gère la file d’incidents, j’ai vu des équipes supposer que la « compatibilité » équivaut à une migration en un clic. Ce n’est pas le cas. Vous migrez l’interface, pas l’infrastructure.

L’interface : ce qui est couvert

Lorsqu’un fournisseur se dit compatible avec Resend, il reproduit généralement l’endpoint d’envoi principal. Vous pouvez ainsi envoyer un payload comme celui-ci :

{ "from": "onboarding@example.com", "to": "user@gmail.com", "subject": "Welcome to the App", "html": "<strong>Hello!</strong>" }

Si l’API est compatible, le serveur renvoie un 200 OK ou un 201 Created avec un identifiant de message. C’est la partie « facile ». Elle vous évite de réécrire votre logique d’intégration ou de changer de SDK. Pour les équipes qui construisent des agents IA, cette cohérence est essentielle. Lorsque des agents déclenchent des e-mails via un serveur MCP ou une carte A2A, ils s’appuient sur des schémas prévisibles pour vérifier que l’effet de bord (l’envoi de l’e-mail) a bien eu lieu.

L’infrastructure : ce qui n’est PAS couvert

La compatibilité s’arrête à la couche HTTP. Tout ce qui se passe après l’acceptation de la requête par l’API est propre au fournisseur.

1. DNS et vérification du domaine

Votre clé API ne transporte pas l’autorisation de votre domaine. Vous ne pouvez pas simplement changer d’URL et vous attendre à ce que vos e-mails soient authentifiés. Vous devez vérifier à nouveau votre domaine auprès du nouveau fournisseur, ce qui implique d’ajouter de nouveaux enregistrements SPF, DKIM et DMARC à votre DNS.

Si vous oubliez de les mettre à jour, vos e-mails seront probablement rejetés ou classés en spam, car le nouveau fournisseur n’est pas autorisé à envoyer en votre nom. Vous pouvez utiliser le vérificateur DNS e-mail de SendHQ pour vérifier que vos enregistrements sont correctement propagés avant de basculer.

2. Réputation d’expéditeur et warm-up d’IP

La réputation est liée à l’IP d’envoi et au domaine. Lorsque vous passez d’un fournisseur à un autre, vous passez souvent sur un nouveau jeu d’IP partagées. Même si votre domaine a une excellente réputation, la nouvelle IP peut être « froide » ou, pire, partagée avec un acteur malveillant.

L’acceptation par le fournisseur (l’API qui répond « OK ») est différente de la livraison (le serveur de réception qui accepte l’e-mail), elle-même différente du placement en boîte de réception (l’e-mail qui arrive dans le dossier principal). La compatibilité couvre l’acceptation par le fournisseur. Elle n’apporte rien pour la livraison ni pour le placement.

3. Webhooks et schémas d’événements

Même si l’API d’envoi est compatible, les événements de webhook (delivered, bounced, complained) ne le sont souvent pas. Si votre système s’appuie sur le suivi des événements de livraison pour déclencher une logique de suivi, vous devez auditer les payloads de webhook du nouveau fournisseur. Un événement bounce dans un système peut être un hard_bounce dans un autre.

Le coût de la compatibilité : réalités tarifaires

La compatibilité vous permet de chercher de meilleurs tarifs sans le coût d’une réécriture complète. Mais les modèles tarifaires varient énormément. D’après les données de septembre 2026 :

• Amazon SES : les tarifs les plus agressifs. À la carte, 0.10 USD pour 1 000 e-mails (tarifs Amazon SES). Les nouvelles formules par paliers introduites le 21 juillet 2026 comprennent Essentials (0.16 USD pour 1 000), Pro (0.22 USD pour 1 000 plus 105 USD par mois et par région) et Enterprise (0.23 USD pour 1 000 plus 500 USD par mois).
• Resend : offre gratuite de 3 000 e-mails par mois (plafonnée à 100 par jour). La formule Pro coûte 20 USD par mois pour 50 000 e-mails, avec des dépassements à 0.90 USD pour 1 000 (tarifs Resend).
• Postmark : 15 USD par mois pour 10 000 e-mails, avec des dépassements entre 1.80 et 1.20 USD pour 1 000 (tarifs Postmark).
• Mailgun : 15 USD par mois pour 10 000 e-mails, avec des dépassements entre 1.80 et 1.10 USD pour 1 000 (tarifs Mailgun).
• SendGrid : l’offre gratuite est désormais un essai de 60 jours, et Essentials démarre à 19.95 USD par mois (tarifs SendGrid).

Pour mettre les choses en perspective : envoyer 50 000 e-mails coûte environ 5 USD avec SES à la carte, mais environ 66 USD avec les paliers de Postmark. La compatibilité d’API rend cette optimisation des coûts possible sans un mois de travail d’ingénierie.

Concevoir pour la fiabilité et pour les agents

Lorsque vous traitez l’e-mail comme un effet de bord externe, en particulier avec des agents IA, vous devez anticiper les échecs. Une API qui renvoie 200 OK ne signifie pas que l’e-mail a atteint l’utilisateur.

Idempotence

Si un agent réessaie une requête après un timeout, vous risquez d’envoyer deux fois le même e-mail, ce qui dégrade l’expérience utilisateur. Utilisez une clé d’idempotence dans vos en-têtes. Ainsi, si la même requête est envoyée deux fois, le fournisseur n’envoie qu’un seul e-mail.

Workflows de validation

Les agents ne doivent pas avoir un accès illimité à votre quota d’envoi. Mettez en place une couche de validation pour les envois à fort volume. Une checklist simple pour les e-mails pilotés par des agents :

1. Validation du schéma : le payload correspond-il à la spécification de l’API compatible ?
2. Limitation de débit : l’agent dépasse-t-il le plafond quotidien (par exemple la limite gratuite de 100/jour de Resend) ?
3. Idempotence : existe-t-il une clé unique pour cette transaction précise ?
4. Humain dans la boucle : cet e-mail nécessite-t-il une validation manuelle avant l’appel API ?

Checklist de migration

Si vous passez à un fournisseur compatible Resend, suivez cette séquence pour éviter un effondrement de la livraison :

• Configuration DNS : configurez SPF, DKIM et DMARC. Consultez notre guide sur l’authentification des e-mails pour vérifier qu’il ne vous manque aucun enregistrement.
• Vérification : utilisez un outil pour confirmer la propagation DNS.
• Warm-up : si vous envoyez des volumes élevés, transférez progressivement le trafic de l’ancien fournisseur vers le nouveau. Ne déplacez pas 100 % du trafic en une heure.
• Audit des webhooks : mappez les types d’événements du nouveau fournisseur aux schémas de votre base de données interne.
• Gestion des erreurs : testez comment le nouveau fournisseur gère les e-mails non valides. Renvoie-t-il un 400 ou un 202 avec un événement de bounce ultérieur ?

Synthèse des compromis

Élément | Couvert par la compatibilité ? | Action requise

Payload de requête | Oui | Aucune (si la spécification correspond)

Format de réponse | Oui | Aucune (si la spécification correspond)

Authentification du domaine | Non | Mettre à jour les enregistrements DNS

Réputation IP | Non | Période de warm-up

Tarifs/quotas | Non | Consulter les pages de tarification des fournisseurs

Événements de webhook | Non | Mettre à jour les écouteurs d’événements

La compatibilité est un outil d’agilité, pas une baguette magique pour la délivrabilité. En séparant l’interface de l’infrastructure, vous pouvez optimiser coûts et performances sans vous enfermer dans l’écosystème d’un seul fournisseur.

Pour une API e-mail prête pour les agents, minimisant la collecte de données, qui simplifie cette infrastructure, découvrez SendHQ.