Quelle API e-mail choisir quand on est développeur ?

Vérification des webhooks et réessais, service par service

Un webhook non vérifié est une porte ouverte sur votre base : n'importe qui peut poster un faux rebond. Les services diffèrent nettement. Resend signe via Svix et réessaie huit fois. Postmark ne signe pas et recommande l'authentification Basic plus une liste d'adresses IP, avec six tentatives. SendGrid propose l'ECDSA ou OAuth 2.0 et réessaie pendant 24 heures glissantes. Mailgun signe en HMAC-SHA256 avec une clé valable pour tout le compte et réessaie environ huit heures. SparkPost envoie des lots identifiés par X-MessageSystems-Batch-ID et réessaie huit heures. Mailjet réessaie toutes les 30 secondes pendant 24 heures et recommande HTTPS avec authentification Basic. Mandrill regroupe jusqu'à 1 000 événements par POST et réessaie jusqu'à 20 fois.

Deux appels pour comparer

Pour un envoi en lot, la référence de Resend montre ce code Node.js, jusqu'à 100 e-mails par appel :

const { data, error } = await resend.batch.send([
  {
    from: 'Acme <onboarding@resend.dev>',
    to: ['foo@gmail.com'],
    subject: 'hello world',
    html: '<h1>it works!</h1>',
  },
  {
    from: 'Acme <onboarding@resend.dev>',
    to: ['bar@outlook.com'],
    subject: 'world hello',
    html: '<p>it works!</p>',
  },
]);

Le guide du premier envoi de Mandrill reste très différent : un appel cURL, la clé d'API dans le corps JSON et un objet message.

curl -sS -X POST "https://mandrillapp.com/api/1.0/messages/send" \
  --header 'Content-Type: application/json' \
  --data-raw "$MESSAGE"

# MESSAGE='{"key": "$YOUR_API_KEY", "message": {"from_email": "hello@example.com", "subject": "Hello World", "text": "Welcome to Mailchimp Transactional!", "to": [{ "email": "freddie@example.com", "type": "to" }]}}'

Le premier garde la clé dans un en-tête d'autorisation (Bearer) et gère l'idempotence par un en-tête ; le second met la clé dans le corps et ne documente rien de tel dans ce guide. Pour une file qui réessaie, cette différence pèse plus que le prix.

Ce que coûte l'envoi à 10 000, 50 000 et 125 000 e-mails

L'écart entre services va de un à dix, mais il dit peu de l'effort : SES économise quelques dizaines de dollars à 50 000 e-mails et coûte des jours d'intégration. Le classement change aussi avec le volume : à 10 000 e-mails, Postmark et Mailgun à 15 $ passent sous Resend Pro, à 125 000 Resend devant les deux.

Six vérifications avant de vous engager

1. Les erreurs et les limites sont-elles lisibles ? Resend renvoie des en-têtes ratelimit-limit, ratelimit-remaining, ratelimit-reset et retry-after ; SendGrid des X-RateLimit-* et un 429 ; Mailjet un 429 par clé et par seconde. Un client qui lit ces valeurs ralentit avant l'échec au lieu de s'acharner.
2. Un réessai peut-il doubler un e-mail ? Seuls Resend et SparkPost documentent une clé d'idempotence de 24 heures parmi les services comparés ici. Avec les autres, votre file doit enregistrer les envois déjà faits, par exemple par identifiant de commande.
3. Les webhooks sont-ils vérifiables ? La signature, le calendrier de réessais et l'identifiant de dédoublonnage décident de la facilité du traitement ; la comparaison est dans la section précédente.
4. Peut-on tester sans toucher la réputation ? Adresses de test chez Resend, jeton de test chez Postmark, sandbox chez SendGrid et SparkPost, simulateur chez SES : un test envoyé à une vraie adresse compte dans le quota et peut produire un vrai rebond.
5. L'historique couvre-t-il vos tickets de support ? Un jour de journal ne répond pas à un client qui écrit une semaine après. Le tableau ci-dessus donne l'ordre de grandeur de chaque service.
6. Le courrier entrant et les listes de suppression sont-ils prévus ? Si votre produit traite les réponses, comparez routes, Inbound Parse et JSON entrant ; si vous gérez des rebonds, vérifiez que la liste de suppression est accessible par API.

Du premier appel à la production, en cinq étapes

Commencez par authentifier le domaine d'envoi (SPF, DKIM, DMARC) et créez une clé limitée à l'envoi, distincte de celle qui gère les domaines et les modèles. Envoyez ensuite vers les adresses de test du service jusqu'à ce que la livraison, le rebond et la plainte produisent chacun l'événement attendu dans votre base. Construisez la clé d'idempotence sur l'événement métier, type-de-message/identifiant, comme le conseille la documentation de Resend. Écrivez le point de terminaison de webhook en lisant le corps brut, en vérifiant la signature ou l'authentification, puis en enregistrant l'identifiant d'événement pour ignorer un doublon. Enfin, surveillez les quotas : Resend renvoie un en-tête x-resend-monthly-quota, et x-resend-daily-quota uniquement pour le plan gratuit, de quoi alerter avant d'atteindre le plafond.