Un API d'e-mail entrant reçoit le courrier envoyé à une adresse ou un domaine que vous possédez, l'analyse, et le transmet à votre application sous forme de POST HTTP structuré. Au lieu d'exécuter un serveur de messagerie et d'interroger une boîte aux lettres via IMAP, vous pointez les enregistrements MX de votre domaine vers le fournisseur, et chaque message entrant arrive à votre endpoint avec les en-têtes, le corps et les pièces jointes déjà analysés en JSON.
Comment fonctionne l'e-mail entrant ?
Le routage commence par le DNS. Vous configurez les enregistrements MX d'un domaine ou sous-domaine (par exemple reply.yourapp.com) pour pointer vers les serveurs de messagerie du fournisseur entrant. Quand quelqu'un envoie un message à une adresse de ce domaine, il arrive sur l'infrastructure du fournisseur plutôt que sur la vôtre. Le fournisseur accepte le message, l'analyse, et envoie une requête POST à l'URL que vous avez enregistrée, avec le contenu analysé.
Un payload analysé inclut généralement l'expéditeur et le destinataire, l'objet, le corps en texte brut et en HTML, l'ensemble des en-têtes, et les éventuelles pièces jointes (souvent encodées en base64 ou référencées par une URL). Votre application lit ce JSON et agit en conséquence, sans code SMTP ou IMAP à maintenir. Le mécanisme de livraison est un webhook : les mêmes règles s'appliquent donc : répondez rapidement avec un 2xx, puis traitez le message de manière asynchrone.
À quoi sert-il ?
L'e-mail entrant transforme les messages reçus en événements applicatifs. Les cas d'usage courants incluent :
- Gestion des réponses. Envoyez une notification depuis
notifications@yourapp.com, et quand un utilisateur répond, la réponse arrive sous forme de POST pour que vous puissiez la rattacher à une conversation. - Ticketing support. Un e-mail envoyé à
support@yourapp.comdevient un nouveau ticket, avec l'expéditeur et le corps directement intégrés dans votre help desk. - Analyse vers base de données. Les reçus transférés ou les e-mails structurés sont analysés et écrits dans une table, sans saisie manuelle.
- E-mail vers action. Un message envoyé à une adresse spéciale déclenche un workflow : créer un enregistrement, lancer une tâche, publier dans un canal.
En quoi est-ce différent de l'envoi d'e-mails ?
Sortant et entrant sont deux fonctions distinctes. Le sortant, c'est votre application qui envoie du courrier aux destinataires via SMTP ou une HTTP d'envoi API. L'entrant, c'est l'inverse : des expéditeurs externes envoient du courrier à votre application. Une intégration e-mail complète fait généralement les deux, envoyer des notifications et recevoir les réponses, mais elles se configurent indépendamment et c'est le côté entrant qui dépend de vos enregistrements MX.
Pourquoi ne pas interroger une boîte aux lettres via IMAP à la place ?
Vous pouvez exécuter un poller IMAP sur une vraie boîte aux lettres, mais cela implique un coût permanent. Vous gérez des identifiants, vous décidez de la fréquence d'interrogation (ce qui ajoute de la latence et des connexions inactives), vous analysez le MIME brut vous-même, et vous suivez les messages déjà traités. Un API entrant élimine la plupart de ces contraintes : le fournisseur analyse le MIME, pousse chaque message une seule fois sous forme de JSON propre, et vous réagissez en quasi temps réel. Pour une comparaison des protocoles sous-jacents, consultez SMTP vs. IMAP.
Questions fréquentes
Quelles modifications DNS dois-je effectuer ?
Vous configurez les enregistrements MX du domaine ou sous-domaine sur lequel vous souhaitez recevoir du courrier pour pointer vers votre fournisseur entrant. Après propagation, le courrier envoyé à n'importe quelle adresse de ce domaine est acheminé vers le fournisseur, qui l'analyse et le poste à votre endpoint. Utiliser un sous-domaine dédié permet de séparer le routage entrant du courrier de votre domaine principal.
Comment les pièces jointes sont-elles gérées ?
Le payload analysé inclut les pièces jointes, généralement encodées en base64 en ligne ou sous forme d'URL que vous récupérez séparément. Votre handler les décode ou les télécharge et les stocke à l'emplacement de votre choix. Les pièces jointes volumineuses sont généralement référencées par URL pour garder le payload compact.
L'e-mail entrant est-il la même chose qu'un webhook ?
La livraison utilise un webhook : le fournisseur envoie à votre application un POST HTTP pour chaque message. La différence est que le payload est un e-mail entièrement analysé plutôt qu'un événement générique. Traitez-le comme n'importe quel webhook en le vérifiant, en répondant rapidement et en le traitant de manière asynchrone.
Pour voir comment Bird gère les deux directions de l'e-mail, commencez par la présentation du produit e-mail et le guide des événements e-mail, qui couvre le modèle de livraison d'événements sur lequel votre handler entrant s'appuiera.