Quelle est la différence en une phrase ?
SMTP est le protocole ouvert par lequel votre logiciel remet un courrier à un serveur ; une API e-mail est une interface HTTPS propre à chaque prestataire, qui fait le même travail avec des données structurées et un retour d'événements. Le protocole de soumission ne décide pas si vous atteignez la boîte de réception — l'authentification et la réputation du domaine le font, et SPF, DKIM et DMARC s'appliquent à l'identique aux deux voies. Choisissez donc sur des critères d'intégration : portabilité, gestion des erreurs, outillage. Pour tout ce qui se passe après que votre prestataire a accepté le message, la délivrabilité pour les startups est le guide.
Comment fonctionne l'envoi en SMTP ?
Votre application ouvre une connexion vers le serveur de votre prestataire, le relais SMTP — pour la soumission, typiquement le port 587 avec authentification, comme le spécifie la RFC 6409 — et lui remet le message finalisé. Le protocole de transfert lui-même, c'est la RFC 5321, normalisée sous sa forme actuelle en 2008 et utilisée depuis bien plus longtemps, et c'est pourquoi tous les logiciels le parlent : n'importe quel framework, CMS, forum, outil de supervision ou script vieux de plusieurs décennies peut envoyer ainsi avec un simple hôte, un port et des identifiants. C'est l'avantage discret de SMTP — migrer revient à changer d'identifiants, donc changer de plateforme e-mail n'implique jamais de réécrire le code d'envoi. C'est aussi la voie naturelle des stacks auto-hébergées, où la prise en charge de SMTP est native.
Comment fonctionne l'envoi via une API e-mail ?
Votre code appelle l'endpoint HTTPS du prestataire avec des données JSON — destinataire, contenu ou référence de modèle, tags, métadonnées, souvent une clé d'idempotence pour éviter les doublons. La réponse est synchrone : un succès avec identifiant de message, ou une erreur que votre code peut intercepter et rejouer. La documentation de Postmark rend le contraste explicite — son API REST renvoie immédiatement un succès ou une erreur, alors que son endpoint SMTP accepte tous les messages et consigne les erreurs sous forme de rebonds, récupérables ensuite via ses webhooks de rebond. Après acceptation, des webhooks renvoient rebonds, plaintes et ouvertures vers votre application — c'est ce qui rend la suppression automatisée possible. Les SDK des prestataires enveloppent tout cela en quelques lignes ; en échange, l'intégration est propre à ce prestataire.
SMTP vs API : le face-à-face
Toute la décision se résume à un arbitrage : SMTP apporte la portabilité, l'API apporte le retour d'information et l'outillage. Voici le détail, ligne par ligne.
| SMTP | API e-mail | |
|---|---|---|
| Ce que c'est | Protocole ouvert (RFC 5321) — le même partout | Interface produit propre au prestataire, via HTTPS |
| Effort d'intégration | Quasi nul si le logiciel parle déjà SMTP : hôte, port, identifiants | S'intégrer à l'endpoint ou au SDK du prestataire |
| Portabilité | Élevée — changer de prestataire revient à changer d'identifiants | Faible — chaque prestataire a son format ; changer implique de réécrire l'intégration |
| Gestion des échecs | Accepté à la soumission ; certains échecs remontent plus tard en rebonds asynchrones | Erreurs synchrones que votre code intercepte et rejoue, plus les événements asynchrones |
| Retour d'événements | Rien dans le protocole — les webhooks de rebond du prestataire couvrent aussi le courrier soumis en SMTP, mais ils se configurent à part | Les webhooks poussent rebonds, plaintes et ouvertures vers votre application |
| Modèles et analytics | Rien dans le protocole — vous envoyez un message finalisé | Références de modèles, tags et métadonnées par message |
| Compatibilité auto-hébergement | Naturelle — les logiciels auto-hébergés parlent SMTP d'office | Une dépendance de plus dans votre stack, propre au prestataire |
Quand SMTP est-il le bon choix ?
- Un logiciel qui le parle déjà — un CMS, un forum, un helpdesk ou une application héritée se met à envoyer via votre prestataire avec de simples identifiants.
- La portabilité maximale — si vous voulez pouvoir changer de prestataire sans toucher au code, SMTP est l'interface neutre.
- Les stacks auto-hébergées — la prise en charge de SMTP est intégrée à presque tout ce que vous feriez tourner sur votre infra, sans SDK.
- Le courrier opérationnel à faible volume — alertes cron et notifications internes justifient rarement une intégration API sur mesure.
Quand l'API est-elle le bon choix ?
L'envoi produit à grande échelle. Quand l'e-mail est câblé dans votre application — accueil, reçus, parcours de cycle de vie — erreurs synchrones, références de modèles et webhooks d'événements justifient leur coût d'intégration, et une liste de suppression peut se mettre à jour dès qu'une adresse rebondit ou se plaint. Une chose que l'API ne vous apporte pas : la réputation. Elle vit sur votre domaine d'envoi, pas sur votre voie de soumission — le préchauffage du domaine et l'authentification s'appliquent à l'identique quel que soit votre mode d'envoi.
Pourquoi fromHello prend-il en charge les deux ?
Parce que ce choix est une décision d'intégration, pas de délivrabilité, la plateforme embarque les deux adaptateurs : fromHello envoie les e-mails via Resend ou via n'importe quel serveur SMTP, au choix par espace de travail. Branchez-la sur le prestataire en qui vous avez déjà confiance. Les limites se fixent au niveau du prestataire dans les deux cas — Resend, par exemple, documente la même limite de débit pour son endpoint SMTP que pour son API. Et suppression et consentement sont appliqués par la plateforme quelle que soit la voie de soumission : une adresse supprimée reste supprimée, que le message parte en HTTPS ou par le port 587.