Comparer les API d'e-mail jetable

1. Faut-il une clé ou un compte pour lire une boîte ?

C'est la question qui décide si le service est seulement utilisable depuis un endroit qui ne peut pas garder un secret : une tâche d'intégration continue sur un fork, un script partagé, un navigateur, un agent IA qui travaille sur la machine de quelqu'un d'autre. Une clé n'est pas une petite friction — c'est un compte, un tableau de bord, une politique de rotation et un coffre à secrets.

Comment y répondre vous-même

Demandez une boîte sans le moindre en-tête. Si la réponse est 200, aucune clé n'est nécessaire. Si c'est 401 ou 403, il en faut une.

curl -s -o /dev/null -w "%{http_code}\n" \
  "https://SERVICE/api/v1/mailbox?address=someone@THEIR-DOMAIN"

Notre réponse

Aucune clé et aucun compte, pour les domaines publics comme pour un domaine à vous. Une clé n'existe que pour le pool premium, parce qu'un pool dont les noms sont publiés cesse de valoir qu'on le paie.

2. Peut-on y pointer son propre domaine, et à quel prix ?

Un domaine à vous, c'est la différence entre une adresse qu'un formulaire d'inscription reconnaît comme jetable et une qu'il ne reconnaît pas. C'est aussi le seul moyen d'avoir une boîte dans laquelle personne ne peut tomber au hasard. La plupart des services soit ne le proposent pas, soit le vendent comme l'offre payante — c'est tout leur modèle, et cela vaut d'être su avant de bâtir sur leur gratuit.

Comment y répondre vous-même

Lisez l'hôte MX qu'ils publient, puis regardez si la documentation vous demande d'enregistrer le domaine chez eux ensuite. Un service qui exige une étape d'inscription a un compte quelque part dans votre avenir.

dig +short MX their-example-domain.com

Notre réponse

Un enregistrement MX vers smtp.grabmail.io, gratuit et sans limite, sur tous les plans y compris le gratuit. Il n'y a aucune étape d'inscription : le premier message qui arrive connecte le domaine, parce que publier l'enregistrement EST la preuve que vous le contrôlez.

3. Combien de temps un message est-il conservé — et est-ce appliqué ou promis ?

Deux services peuvent tous deux dire « sept jours » et vouloir dire autre chose. L'un supprime sur un calendrier ; l'autre supprime quand le stockage se remplit. Pour une suite de tests, le nombre importe peu. Pour tout ce que vous préféreriez ne pas laisser traîner, la différence entre une fenêtre appliquée et une fenêtre annoncée est tout l'enjeu.

Comment y répondre vous-même

Envoyez-vous un message, notez la date que l'API renvoie, et revenez après la fenêtre. Le mot à chercher dans leur texte est « jusqu'à » : il veut dire que le nombre est un plafond, pas un calendrier.

curl -s "https://SERVICE/api/v1/mailbox?address=…" | grep -o '"date":"[^"]*"'

Notre réponse

5 jours exactement, appliqués par une tâche qui tourne toutes les dix minutes, pas par une phrase sur une page de politique. Ce n'est pas un palier : aucun plan, paramètre ni demande ne l'allonge. Catchmail — le service d'où la plupart des gens arrivent ici — garde le courrier jusqu'à sept jours, soit plus longtemps que nous.

4. Un programme peut-il attendre un message, ou doit-il interroger en boucle ?

Un test qui interroge en boucle doit choisir un intervalle d'attente, et les deux choix sont mauvais : trop court, il épuise la limite de débit ; trop long, la suite prend plusieurs minutes de plus que nécessaire. Un agent IA a le même problème et ne peut pas le résoudre du tout — il n'a pas d'adresse publique pour un webhook, ni la patience d'une boucle.

Comment y répondre vous-même

Cherchez soit un webhook dans la référence, soit un appel qui bloque. Si la documentation ne montre qu'un point d'accès de liste, la réponse est l'interrogation en boucle, qu'elle le dise ou non.

curl -s https://SERVICE/openapi.json | grep -o '"/[a-z/{}._-]*"'

Notre réponse

Les deux, et aucun n'exige d'adresse publique de votre côté. L'API REST s'interroge en boucle — 1 lecture par seconde et par adresse est le rythme prévu. Le serveur MCP a un outil qui garde l'appel ouvert jusqu'à l'arrivée réelle du message, jusqu'à 25 secondes : c'est ce dont un agent a besoin et ce qu'un webhook ne peut pas lui donner.

5. Que se passe-t-il quand un formulaire d'inscription refuse l'adresse ?

Cela arrivera, sur tout service à domaines publics partagés, et c'est le moment où la plupart des gens abandonnent en concluant que l'e-mail jetable « ne marche pas ». Ce qui distingue les services ici n'est pas que cela arrive, mais qu'ils vous l'aient dit à l'avance et ce qu'ils vous laissent ensuite.

Comment y répondre vous-même

Cherchez le domaine public dans une liste de blocage que les formulaires d'inscription utilisent vraiment. S'il y figure, attendez-vous à des refus — et regardez ce que le service propose ensuite.

grep -x their-domain.com <(curl -s https://raw.githubusercontent.com/disposable/disposable-email-domains/master/domains.txt)

Notre réponse

Dit sur la page d'accueil, dans la FAQ et dans llms.txt plutôt que découvert. Deux sorties, et la gratuite vient en premier : pointez ici un domaine à vous, qui ne coûte rien et n'a aucune limite ; ou, si vous préférez ne pas en posséder ni en exposer un, un pool payant de 92 domaines en .com tenus à l'écart de ces listes. Les domaines publics restent gratuits dans les deux cas.

6. Peut-il envoyer du courrier — et le voulez-vous ?

Un service qui ne fait que recevoir ne peut pas être transformé en relais à spam, et c'est pourquoi son serveur entrant peut se permettre d'accepter le courrier de tout domaine qui pointe vers lui. Un service qui sait envoyer finira par être détourné, et le détournement est ce qui met fin aux offres gratuites. S'il vous faut envoyer, toute cette catégorie est le mauvais outil.

Comment y répondre vous-même

Cherchez un POST qui prend un destinataire. Si la référence en a un, le service sait envoyer ; s'il n'en a aucun, il ne le sait pas, et c'est généralement délibéré.

curl -s https://SERVICE/openapi.json | grep -c '"post"'

Notre réponse

Non. Il n'existe aucun point d'accès qui envoie et aucun courrier sortant d'aucune sorte — pas même celui d'une réinitialisation de mot de passe. C'est cette absence qui permet à l'arête entrante d'accepter le courrier de tout domaine dont le MX pointe ici sans devenir un relais.

Nos réponses, au même endroit

Chaque chiffre de ce tableau est lu dans les constantes que le service applique : il ne peut pas être en désaccord avec l'API.

Migrer une intégration existante

Cette catégorie s'est arrêtée sur trois appels, et la plupart des services les exposent aux trois mêmes chemins. La migration se réduit d'ordinaire à l'URL de base et à la boucle de pagination.

GET    /api/v1/mailbox?address=<address>
GET    /api/v1/message/<id>?mailbox=<address>
DELETE /api/v1/message/<id>?mailbox=<address>

Catchmail, le service d'où l'on arrive le plus souvent ici, utilise ces trois mêmes chemins. Deux choses diffèrent, et les deux sont dans la pagination : leur liste répond avec page / page_size et un total, la nôtre répond avec un curseur next que vous renvoyez pour parcourir la suite. Leur URL de base est un sous-domaine ; la nôtre est le site lui-même. Tout le reste — les noms de champs, les codes de statut, la forme d'un message — se correspond.

Une chose que vous gagnez et une que vous perdez, pour peser : chaque boîte porte ici un alias — une seconde adresse qui livre dans la boîte sans permettre de la lire, et c'est elle qu'on donne au formulaire auquel on s'inscrit. Et la rétention est ici de 5 jours plutôt que sept.

Les détails concernant des tiers sur cette page ont été vérifiés dans la documentation publiée par chaque service le 2026-08-31.

La référence complète de l'API · Démarrage rapide · Tarifs

Les questions que l'on se pose vraiment

Quelle est la meilleure API d'e-mail jetable ?

Il n'y a pas de réponse unique, et une page qui vous en donnerait une vous vendrait quelque chose. Les six questions ci-dessus sont celles qui diffèrent réellement d'un service à l'autre ; trois d'entre elles se règlent par une seule commande, et les réponses tranchent pour votre cas plutôt qu'en général.

Je migre depuis une autre API d'e-mail jetable. Qu'est-ce qui doit changer ?

En général l'URL de base et la boucle de pagination. Les trois chemins sur lesquels cette catégorie s'est arrêtée sont presque partout les mêmes — lister une boîte, lire un message, le supprimer — et ce qui diffère est la façon dont la liste est paginée et le nom des champs.

Conservez-vous les messages plus longtemps que le service que j'utilise ?

Probablement pas. 5 jours, c'est court à dessein, et c'est une limite dure, pas un palier. Si votre suite de tests a besoin d'un message une heure après son arrivée, c'est parfait ; s'il vous en faut un la semaine prochaine, récupérez-le et stockez-le chez vous.

Y a-t-il une garantie de disponibilité ?

Non, et aucune n'est vendue. Ce qui existe à la place est une page d'état qui refuse de déclarer un composant sain tant qu'un moniteur ne l'a pas confirmé récemment — un contrôle périmé y est montré comme une absence de contrôle, pas comme une bonne nouvelle.