Reusable.Email
All articles
developerAPIemail testingSMTPIMAP

API e-mail pour les développeurs : boîtes de réception jetables, identifiants SMTP et webhooks

Un guide du développeur pour l'e-mail programmatique — API e-mail jetable, identifiants SMTP, accès IMAP et webhooks pour les tests, le staging et les produits SaaS.

September 8, 2025·14 min de lecture·Reusable.Email
API e-mail pour les développeurs : boîtes de réception jetables, identifiants SMTP et webhooks

Les développeurs ont besoin d'e-mail pour des choses qui n'ont rien à voir avec la communication. Les suites de tests automatisés doivent envoyer et recevoir des messages. Les environnements de staging ont besoin de boîtes de réception isolées qui ne fuient pas vers les utilisateurs de production. Les produits SaaS doivent donner à chaque client une vraie adresse e-mail. Les plateformes de courrier temporaire ont besoin d'un backend qui fonctionne réellement.

Tout cela nécessite un contrôle programmatique sur l'e-mail — créer des boîtes de réception, envoyer des messages, lire les réponses, réagir aux événements de livraison. Ce guide couvre comment construire chacun de ces cas d'usage en utilisant des protocoles standard et une infrastructure abordable.

Pourquoi les développeurs ont besoin d'une API e-mail

Le mot « API » dans le contexte de l'e-mail signifie généralement l'une de deux choses : une API REST propriétaire pour l'envoi et la réception (comme SendGrid ou Mailgun), ou des protocoles standard — IMAP et SMTP — que chaque langage de programmation a déjà des bibliothèques.

Les API propriétaires conviennent à l'envoi transactionnel. Vous appelez un point de terminaison, passez une charge utile et le service livre l'e-mail. Mais quand vous avez besoin de recevoir de l'e-mail, de lire de l'e-mail, d'organiser de l'e-mail ou de donner aux utilisateurs leur propre boîte de réception, les API d'envoi propriétaires ne suffisent pas. Vous avez besoin de la pile d'e-mail complète.

Les cas d'usage qui poussent les développeurs à chercher une API e-mail se répartissent généralement en quatre catégories :

  • Tests et assurance qualité : Vérifier que votre application envoie les bons e-mails, avec le bon contenu, aux bonnes adresses
  • Isolation de staging : S'assurer que les environnements de développement et de staging ne fuient pas d'e-mail vers les adresses de production
  • Boîtes de réception par utilisateur : Donner à chaque utilisateur de votre application sa propre adresse e-mail pour recevoir et envoyer
  • Construction de produits d'e-mail : Créer des services de courrier temporaire, des outils de confidentialité ou des plateformes basées sur l'e-mail

Chacun d'eux a des exigences différentes, mais ils partagent tous la même fondation : vous avez besoin de vraies boîtes de réception avec de vrais identifiants avec lesquels vous pouvez interagir programmatiquement.

Trois approches de l'e-mail en développement

Chaque équipe finit par se concentrer sur l'une des trois stratégies pour gérer l'e-mail en dehors de la production.

1. Comptes e-mail réels

L'approche la plus simple : créez des comptes Gmail ou Outlook et codez-les en dur dans vos tests et votre environnement de staging.

Cela fonctionne jusqu'à ce que ce ne soit pas le cas. Gmail limite l'accès programmatique. Google exige OAuth2 pour les connexions IMAP — vous ne pouvez pas juste passer un nom d'utilisateur et un mot de passe. Les identifiants partagés sont tournés et cassent CI. Les e-mails de test fuient vers les vraies boîtes de réception. Un développeur envoie accidentellement 500 notifications de test à l'adresse d'un client depuis le staging. Le coût du « simple » s'ajoute rapidement.

Il y a aussi la surcharge de gestion de compte. Créer un nouveau compte Gmail pour chaque environnement de test signifie gérer 2FA, les mots de passe d'application et la détection de bot de plus en plus agressive de Google. C'est une infrastructure fragile construite sur un service qui n'a pas été conçu pour ce cas d'usage.

2. Bacs à sable e-mail

Des outils comme Mailtrap interceptent les e-mails sortants et les affichent dans un tableau de bord. Votre application pense envoyer un vrai e-mail, mais rien n'est réellement livré.

Les bacs à sable sont utiles pour vérifier les modèles HTML et attraper les envois accidentels. Mais ils ne peuvent pas tester la livraison réelle. Vous ne pouvez pas vérifier qu'un e-mail arrive réellement dans une boîte de réception, soit analysé correctement par un client IMAP ou déclenche un webhook. Pour les tests de bout en bout, les bacs à sable sont incomplets.

Il y a aussi l'écart de protocole. Les bacs à sable vous donnent SMTP (pour l'envoi) mais pas IMAP (pour la lecture). Vos tests peuvent affirmer qu'un e-mail a été capturé par le bac à sable, mais ils ne peuvent pas tester le flux de récupération complet que votre code de production utilise. En savoir plus sur ce compromis dans notre guide de test SMTP.

3. Boîtes de réception réelles à la demande

La troisième approche consiste à créer des boîtes de réception e-mail réelles programmatiquement — des boîtes de réception avec des identifiants IMAP et SMTP réels qui envoient et reçoivent de vrais e-mails. Cela vous donne une couverture de bout en bout complète sans les risques d'utiliser des comptes personnels.

C'est ce que les boîtes de réception gérées de Reusable.Email fournissent. Chaque boîte de réception gérée est un compte e-mail complet avec accès IMAP, SMTP et POP3. Vous la créez, l'utilisez dans vos tests ou votre produit, et elle fonctionne avec n'importe quelle bibliothèque e-mail dans n'importe quel langage.

L'avantage clé est la compatibilité de protocole. Parce que les boîtes de réception gérées utilisent IMAP et SMTP standard, votre code de test et votre code de production utilisent les mêmes bibliothèques, les mêmes modèles de connexion et la même gestion des erreurs. Il n'y a pas de couche d'abstraction réservée aux tests qui cache le comportement du monde réel.

Reusable.Email pour les développeurs

Une boîte de réception gérée sur Reusable.Email coûte 3 $ une fois — pas mensuellement, pas par siège, pas basé sur l'utilisation. Ces 3 $ vous donnent :

  • Accès IMAP à imap.reusable.email:993 (SSL/TLS)
  • Accès SMTP à smtp.reusable.email:587 (STARTTLS)
  • Accès POP3 pour les clients qui le préfèrent
  • Conservation d'e-mail de 365 jours
  • Dossiers personnalisés, filtrage des spams, transfert, envoi/réponse
  • Fonctionne avec Apple Mail, Thunderbird, Outlook ou n'importe quelle bibliothèque standard

Pour les équipes construisant des produits au-dessus de l'e-mail, le niveau white-label (30 $/mois) ajoute une API REST, les webhooks pour les événements e-mail, un panneau d'administration et aucune marque Reusable.Email. Plus de détails dans le guide du service d'e-mail white-label.

Cas d'usage 1 : tests d'e-mail et assurance qualité

Les tests automatisés impliquant l'e-mail doivent généralement :

  1. Créer une boîte de réception fraîche pour l'exécution du test
  2. Déclencher une action qui envoie un e-mail (inscription, réinitialisation de mot de passe, notification)
  3. Lire la boîte de réception et affirmer le contenu de l'e-mail
  4. Nettoyer

Avec les boîtes de réception gérées, chaque suite de test (ou même chaque test) obtient sa propre vraie boîte de réception. Puisque la boîte de réception supporte IMAP standard, vous lisez les messages en utilisant n'importe quelle bibliothèque IMAP — pas de SDK propriétaire requis.

Le flux de travail de test ressemble à ceci : votre pipeline CI démarre, votre code de test se connecte à une boîte de réception gérée via IMAP, votre application en test envoie un e-mail (réinitialisation de mot de passe, e-mail de bienvenue, notification) et votre code de test sonde la boîte de réception IMAP jusqu'à ce que l'e-mail arrive. Ensuite, vous analysez l'e-mail, affirmez son contenu (sujet correct, corps correct, liens corrects) et allez de l'avant. Si l'e-mail n'arrive pas dans un délai d'expiration, le test échoue — ce qui est exactement ce qui devrait se passer si votre pipeline d'e-mail est cassé.

Le modèle de coûts rend cela pratique. Dix boîtes de réception de test permanentes coûtent 30 $ au total, une fois. Comparez cela au 15-35 $/mois de Mailtrap ou à la tarification par siège de Mailinator. Sur un an, la différence est importante.

Pour une description détaillée de mise en œuvre avec les codes Python et Node.js, consultez How to Build an Email Testing Environment with a Disposable Email API.

Cas d'usage 2 : environnements de staging

Les environnements de staging ont besoin d'e-mail qui se comporte comme la production mais reste isolé. Les exigences :

  • Les e-mails sortants de staging ne doivent jamais atteindre les utilisateurs réels
  • Les développeurs doivent inspecter ce qui a été envoyé
  • Idéalement, vous pouvez tester la boucle d'envoi-réception complète

Une boîte de réception gérée par environnement de staging résout cela. Configurez votre application de staging pour envoyer via smtp.reusable.email:587 avec les identifiants de cette boîte de réception. L'e-mail sortant va à une vraie boîte de réception que vous contrôlez. Vous pouvez la lire via IMAP, la transférer ou juste vérifier l'interface web.

Parce que les identifiants SMTP sont limités à une boîte de réception gérée spécifique, il n'y a aucun risque que l'e-mail de staging fuie vers les adresses de production. La boîte de réception est isolée par conception.

Une configuration typique pour une équipe exécutant plusieurs environnements :

Quatre boîtes de réception, 12 $ au total, permanentes. L'e-mail de chaque environnement est complètement isolé des autres.

Cas d'usage 3 : boîtes de réception par utilisateur dans votre application SaaS

Certains produits doivent donner aux utilisateurs leur propre adresse e-mail. Les systèmes de billetterie, les plates-formes de service client, les outils CRM, les applications de gestion de projet — tous bénéficient de permettre aux utilisateurs de recevoir du courrier directement dans le produit.

L'approche traditionnelle consiste à exécuter votre propre serveur de courrier. Postfix, Dovecot, enregistrements DNS, filtrage des spams, surveillance de la livraison, gestion du stockage. C'est un travail à temps plein.

Avec Reusable.Email, vous créez une boîte de réception gérée pour chaque utilisateur. Ils obtiennent de vrais identifiants IMAP/SMTP. Votre application se connecte via IMAP pour extraire les messages, ou utilise les webhooks (niveau white-label) pour être notifiée en temps réel. L'utilisateur voit l'e-mail dans votre produit ; vous ne touchez jamais un serveur de courrier.

À 3 $ par boîte de réception, donner à 1 000 utilisateurs leur propre adresse e-mail coûte 3 000 $ — une fois. Aucun coût de mise à l'échelle mensuelle. Lisez l'architecture complète dans On-Demand SMTP & IMAP Credentials.

Cas d'usage 4 : construction d'un produit de courrier temporaire

Si vous construisez un service d'e-mail temporaire, un outil de confidentialité ou n'importe quel produit où les boîtes de réception jetables sont la fonctionnalité principale, le niveau white-label est conçu pour cela.

Pour 30 $/mois vous obtenez :

  • Boîtes de réception gérées illimitées sur votre domaine
  • Zéro marque Reusable.Email
  • API REST complète pour la création et la gestion des boîtes de réception
  • Webhooks pour les événements e-mail en temps réel
  • Tableau de bord d'analyse d'utilisation
  • Panneau d'administration pour gérer les comptes et les domaines

Vos utilisateurs voient votre marque. L'infrastructure est gérée. Vous vous concentrez sur le produit. Consultez le guide du service d'e-mail white-label pour la ventilation complète.

Référence de protocole : IMAP, SMTP et POP3

Avant de plonger dans le code, voici une référence rapide pour se connecter aux boîtes de réception gérées Reusable.Email.

Protocole Host Port Chiffrement Objectif
IMAP imap.reusable.email 993 SSL/TLS Lire l'e-mail, rechercher, gérer les dossiers
SMTP smtp.reusable.email 587 STARTTLS Envoyer du courrier
POP3 pop.reusable.email 995 SSL/TLS Télécharger du courrier (alternative à IMAP)

L'authentification pour tous les protocoles utilise l'adresse e-mail de la boîte de réception comme nom d'utilisateur et le mot de passe de la boîte de réception. Pas OAuth2, pas de mots de passe spécifiques à l'application, pas de clés API. Des identifiants standard qui fonctionnent avec chaque bibliothèque e-mail.

IMAP vs POP3 : IMAP garde les messages sur le serveur et supporte les dossiers, la recherche et les drapeaux. POP3 télécharge les messages et (par défaut) les supprime du serveur. Pour l'accès programmatique, IMAP est presque toujours le meilleur choix — il vous permet de rechercher, filtrer et gérer l'état côté serveur.

Intégration IMAP : lecture des e-mails programmatiquement

Chaque boîte de réception gérée supporte IMAP à imap.reusable.email:993 avec SSL/TLS. Voici comment se connecter et lire les messages en Python :

import imaplib
import email
from email.header import decode_header

# Connectez-vous au serveur Reusable.Email IMAP
imap = imaplib.IMAP4_SSL("imap.reusable.email", 993)
imap.login("[email protected]", "your-password")

# Sélectionnez la boîte de réception
imap.select("INBOX")

# Recherchez tous les messages non lus
status, messages = imap.search(None, "UNSEEN")
message_ids = messages[0].split()

for msg_id in message_ids:
    # Récupérez l'e-mail
    status, msg_data = imap.fetch(msg_id, "(RFC822)")
    raw_email = msg_data[0][1]

    # Analysez l'e-mail
    msg = email.message_from_bytes(raw_email)

    subject, encoding = decode_header(msg["Subject"])[0]
    if isinstance(subject, bytes):
        subject = subject.decode(encoding or "utf-8")

    sender = msg.get("From")
    print(f"From: {sender}")
    print(f"Subject: {subject}")

    # Obtenez le corps de l'e-mail
    if msg.is_multipart():
        for part in msg.walk():
            content_type = part.get_content_type()
            if content_type == "text/plain":
                body = part.get_payload(decode=True).decode()
                print(f"Body: {body}")
                break
    else:
        body = msg.get_payload(decode=True).decode()
        print(f"Body: {body}")

imap.logout()

C'est un imaplib standard — pas de SDK propriétaire, pas de verrouillage du fournisseur. N'importe quelle bibliothèque IMAP dans n'importe quel langage fonctionne de la même manière.

Attendre l'e-mail dans les tests

Dans les tests automatisés, vous devez souvent attendre qu'un e-mail arrive. Voici un modèle de sondage :

import time

def wait_for_email(imap, subject_contains, timeout=30, interval=2):
    """Sondez la boîte de réception IMAP jusqu'à ce qu'un e-mail correspondant au sujet arrive."""
    start = time.time()
    while time.time() - start < timeout:
        imap.select("INBOX")
        status, messages = imap.search(None, "UNSEEN")
        for msg_id in messages[0].split():
            status, msg_data = imap.fetch(msg_id, "(RFC822)")
            msg = email.message_from_bytes(msg_data[0][1])
            subject = decode_header(msg["Subject"])[0][0]
            if isinstance(subject, bytes):
                subject = subject.decode()
            if subject_contains.lower() in subject.lower():
                return msg
        time.sleep(interval)
    raise TimeoutError(f"No email with '{subject_contains}' in subject after {timeout}s")

Pour la livraison en temps réel sans sondage, les webhooks du niveau white-label poussent les événements vers votre point de terminaison au moment où un e-mail arrive. Plus de détails dans How to Receive Emails via API.

Intégration SMTP : envoi d'e-mails programmatiquement

Chaque boîte de réception gérée a également un accès SMTP à smtp.reusable.email:587 avec STARTTLS. Voici un exemple Node.js utilisant nodemailer :

const nodemailer = require("nodemailer");

const transporter = nodemailer.createTransport({
  host: "smtp.reusable.email",
  port: 587,
  secure: false, // STARTTLS
  auth: {
    user: "[email protected]",
    pass: "your-password",
  },
});

async function sendTestEmail() {
  const info = await transporter.sendMail({
    from: "[email protected]",
    to: "[email protected]",
    subject: "Test email from staging",
    text: "This is a test email sent via Reusable.Email SMTP.",
    html: "<p>This is a <b>test email</b> sent via Reusable.Email SMTP.</p>",
  });

  console.log("Message sent:", info.messageId);
}

sendTestEmail();

Parce que c'est SMTP standard, la même approche fonctionne avec n'importe quel langage : le smtplib de Python, Net::SMTP de Ruby, net/smtp de Go, PHPMailer de PHP, Jakarta Mail de Java.

Exemple Python SMTP

Pour l'exhaustivité, voici l'équivalent Python utilisant smtplib :

import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart

def send_email(to_address, subject, text_body, html_body=None):
    msg = MIMEMultipart("alternative")
    msg["Subject"] = subject
    msg["From"] = "[email protected]"
    msg["To"] = to_address

    msg.attach(MIMEText(text_body, "plain"))
    if html_body:
        msg.attach(MIMEText(html_body, "html"))

    with smtplib.SMTP("smtp.reusable.email", 587) as server:
        server.starttls()
        server.login("[email protected]", "your-password")
        server.send_message(msg)

send_email(
    "[email protected]",
    "Order Confirmation",
    "Your order #1234 has been confirmed.",
    "<h1>Order Confirmed</h1><p>Your order #1234 has been confirmed.</p>",
)

Envoi avec pièces jointes

L'ajout de pièces jointes suit l'approche MIME standard :

from email.mime.base import MIMEBase
from email import encoders

def send_with_attachment(to_address, subject, body, file_path):
    msg = MIMEMultipart()
    msg["Subject"] = subject
    msg["From"] = "[email protected]"
    msg["To"] = to_address
    msg.attach(MIMEText(body, "plain"))

    with open(file_path, "rb") as f:
        attachment = MIMEBase("application", "octet-stream")
        attachment.set_payload(f.read())
        encoders.encode_base64(attachment)
        attachment.add_header(
            "Content-Disposition",
            f"attachment; filename={file_path.split('/')[-1]}",
        )
        msg.attach(attachment)

    with smtplib.SMTP("smtp.reusable.email", 587) as server:
        server.starttls()
        server.login("[email protected]", "your-password")
        server.send_message(msg)

Rien ici n'est spécifique à Reusable.Email. C'est le même code que vous écririez pour n'importe quel serveur SMTP. C'est le point — pas de verrouillage du fournisseur, pas de SDK propriétaire à apprendre et maintenir.

Webhooks : événements e-mail en temps réel

Le niveau white-label supporte les webhooks qui notifient votre application quand des événements e-mail se produisent. Quand un e-mail arrive à n'importe quelle boîte de réception gérée dans votre domaine, Reusable.Email envoie un POST HTTP à votre point de terminaison configuré avec les détails du message.

C'est l'approche pour les produits qui ont besoin du traitement d'e-mail en temps réel — pas de délai de sondage, pas de connexions IMAP persistantes, pas d'e-mails manqués.

La charge utile typique du webhook inclut :

  • Expéditeur, destinataire, sujet
  • Corps en texte brut et HTML
  • Métadonnées de pièce jointe
  • Horodatage de livraison

Votre point de terminaison reçoit l'événement, le traite (extraire les codes de vérification, acheminer vers le bon utilisateur, déclencher la logique d'application) et répond avec un statut 200.

Pour une comparaison complète du sondage IMAP vs webhooks vs sondage API, consultez How to Receive Emails via API.

Considérations de sécurité

Lors de l'utilisation des identifiants e-mail en développement, test et production, les pratiques de sécurité standard s'appliquent :

Stockez les identifiants dans des variables d'environnement ou un gestionnaire de secrets. Ne codez jamais les mots de passe de la boîte de réception en dur dans le code source. Utilisez la gestion des secrets de votre plateforme CI (secrets GitHub Actions, variables CI GitLab, etc.) pour les pipelines automatisés.

Utilisez des boîtes de réception séparées par environnement. Ne partagez pas la même boîte de réception gérée entre le développement, le staging et la production. L'isolation empêche la contamination entre environnements et limite le rayon d'explosion des identifiants compromis.

Tournez les mots de passe s'ils sont compromis. Si un mot de passe de boîte de réception est accidentellement validé dans un référentiel public, changez-le immédiatement via l'interface Reusable.Email.

TLS partout. IMAP (port 993, SSL/TLS) et SMTP (port 587, STARTTLS) utilisent tous deux des connexions chiffrées. Votre contenu d'e-mail et vos identifiants ne sont jamais transmis en texte brut.

Modèle de tarification pour les développeurs

La plupart des services de test d'e-mail et d'API facturent des frais mensuels par siège. Voici comment Reusable.Email se compare :

Service Modèle de tarification Coût pour 10 boîtes de réception/an
Reusable.Email 3 $ par boîte de réception une fois 30 $ (une fois)
Mailtrap 15-35 $/mois 180-420 $/an
Mailinator Abonnement par siège 200 $/an +
Mailosaur Abonnement par siège 300 $/an +

La tarification unique signifie que vos coûts d'infrastructure d'e-mail sont prévisibles et ne s'adaptent pas à la taille de l'équipe ou au temps. Une startup et une équipe de 50 personnes paient le même par boîte de réception.

Pour les équipes qui ont besoin de l'infrastructure API et des webhooks complets, le niveau white-label à 30 $/mois inclut les boîtes de réception gérées illimitées — le coût par boîte de réception tombe à zéro une fois que vous êtes sur ce plan.

FAQ

Comment créer les boîtes de réception programmatiquement ?

Sur le niveau white-label, vous utilisez l'API REST pour créer des boîtes de réception gérées. Chaque boîte de réception obtient ses propres identifiants IMAP/SMTP. Pour une utilisation à plus petite échelle, vous pouvez créer des boîtes de réception gérées via l'interface web de Reusable.Email et utiliser les identifiants dans votre code.

Quels protocoles Reusable.Email supporte-t-il ?

Toutes les boîtes de réception gérées supportent IMAP (port 993, SSL/TLS), SMTP (port 587, STARTTLS) et POP3. Ce sont des protocoles standard qui fonctionnent avec n'importe quelle bibliothèque e-mail ou client.

Puis-je recevoir des e-mails via webhook ?

Oui, sur le niveau white-label. Les webhooks envoient un POST HTTP à votre point de terminaison quand l'e-mail arrive à n'importe quelle boîte de réception gérée dans votre domaine. Pour d'autres niveaux, utilisez le sondage IMAP. Consultez le guide API de réception d'e-mail pour les détails de mise en œuvre.

Combien coûte la création de 100 boîtes de réception de test ?

300 $, une fois. C'est 100 boîtes de réception gérées à 3 $ chacune. Pas de frais mensuels, pas de renouvellement. Si vous avez besoin de plus d'environ 10 boîtes de réception, le niveau white-label à 30 $/mois inclut la création de boîte de réception illimitée via API, ce qui devient moins cher à l'échelle.

Y a-t-il une API officielle ?

Le niveau white-label inclut une API REST complète pour créer et gérer les boîtes de réception, les domaines et les comptes. Pour le niveau de boîte de réception gérée standard, vous interagissez via les protocoles IMAP/SMTP standard — qui sont eux-mêmes une API que chaque langage de programmation supporte dès le départ.

Puis-je utiliser Reusable.Email avec ma bibliothèque e-mail existante ?

Oui. N'importe quelle bibliothèque qui supporte IMAP et SMTP fonctionne dès le départ. Cela inclut le imaplib et smtplib de Python, nodemailer et imapflow de Node.js, net/imap et net/smtp de Ruby, net/smtp de Go, PHPMailer de PHP, Jakarta Mail de Java et bien d'autres. Pas de SDK à installer.

Pendant combien de temps les e-mails sont-ils conservés ?

Les boîtes de réception gérées conservent les e-mails pendant 365 jours. Après cela, les messages sont automatiquement supprimés. Si vous avez besoin d'une rétention plus longue, tirez les messages dans votre propre stockage via IMAP.

Puis-je utiliser un domaine personnalisé ?

Oui. Les domaines personnalisés (10 $/an) vous permettent de créer des boîtes de réception à [email protected]. Le niveau white-label inclut le support de domaine personnalisé avec configuration automatique MX, SPF, DKIM et DMARC.

Conclusion

L'e-mail en développement n'a pas besoin d'être compliqué ou coûteux. Les protocoles standard — IMAP et SMTP — ont été l'épine dorsale de l'e-mail pendant des décennies, et ils fonctionnent avec chaque langage et framework.

Reusable.Email donne aux développeurs des boîtes de réception réelles avec des identifiants réels à un coût unique. Aucune limitation de bac à sable, aucun tapis roulant d'abonnement, aucun SDK propriétaire. Pour les équipes construisant des produits sur l'e-mail, le niveau white-label ajoute la couche API et les webhooks nécessaires pour l'utilisation en production.

Que vous écriviez des tests, isoliez le staging, donniez aux utilisateurs leur propre boîte de réception ou construisiez le prochain service de courrier temporaire — l'infrastructure est la même : créez une boîte de réception, obtenez les identifiants, connectez-vous avec les protocoles standard.

Try it free

Get a disposable inbox in seconds

No sign-up required. Just visit an address and it's live. Works with any domain on reusable.email.

Open your inbox →

Related Articles

Back to all articles