Email API für Entwickler: Disposable Inboxes, SMTP-Credentials & Webhooks

Entwickler brauchen E-Mail für Dinge, die nichts mit Kommunikation zu tun haben. Automatisierte Test-Suites müssen Nachrichten senden und empfangen. Staging-Umgebungen brauchen isolierte Posteingänge, die nicht zu Produktions-Benutzern durchsickern. SaaS-Produkte müssen jedem Kunden eine echte E-Mail-Adresse geben. Temp-Mail-Plattformen brauchen ein Backend, das tatsächlich funktioniert.

Alle erfordern programmgesteuerte Kontrolle über E-Mail – Posteingänge erstellen, Nachrichten senden, Antworten lesen, auf Zustellungsereignisse reagieren. Dieser Guide zeigt, wie man jeden dieser Use-Cases mit Standard-Protokollen und erschwinglicher Infrastruktur baut.

Warum Entwickler eine Email API brauchen

Das Wort „API" im Kontext von E-Mail bedeutet normalerweise eines von zwei Dingen: eine proprietäre REST API zum Senden und Empfangen (wie SendGrid oder Mailgun) oder Standard-Protokolle – IMAP und SMTP – die jede Programmiersprache bereits hat Bibliotheken für.

Proprietäre APIs sind fein für transaktionales Senden. Sie rufen einen Endpoint auf, geben ein Payload auf und der Service stellt die E-Mail zu. Aber wenn Sie E-Mail empfangen, E-Mail lesen, E-Mail organisieren oder Benutzern ihren eigenen Posteingang geben müssen, sind proprietäre Sende-APIs nicht genug. Sie brauchen den vollständigen Email-Stack.

Die Use-Cases, die Entwickler zu einer E-Mail-API führen, fallen typischerweise in vier Kategorien:

• Testen und QA: Überprüfung, dass Ihre Anwendung die richtigen E-Mails mit dem richtigen Content an die richtigen Adressen sendet
• Staging-Isolation: Sicherstellung, dass Entwicklungs- und Staging-Umgebungen nicht E-Mail zu Produktions-Benutzern durchsickern lassen
• Pro-Benutzer-Posteingänge: Jedem Benutzer in Ihrer Anwendung ihre eigene E-Mail-Adresse zum Empfangen und Senden geben
• E-Mail-Produkte bauen: Erstellen von Temp-Mail-Services, Datenschutz-Tools oder E-Mail-basierten Plattformen

Jede hat unterschiedliche Anforderungen, aber alle teilen die gleiche Grundlage: Sie brauchen echte Posteingänge mit echten Credentials, mit denen Sie programmgesteuert interagieren können.

Drei Ansätze zu E-Mail in der Entwicklung

Jedes Team landet letztendlich bei einer von drei Strategien für die Behandlung von E-Mail außerhalb der Produktion.

1. Echte E-Mail-Konten

Der einfachste Ansatz: Gmail oder Outlook-Konten erstellen und sie fest in Ihre Tests und Staging-Umgebung kodieren.

Das funktioniert, bis es nicht mehr funktioniert. Gmail rate-limited programmgesteuerten Zugang. Google erfordert OAuth2 für IMAP-Verbindungen – Sie können nicht einfach einen Benutzernamen und ein Passwort übergeben. Gemeinsame Credentials werden rotiert und brechen CI. Test-E-Mails durchsickern zu echten Posteingängen. Ein Entwickler sendet versehentlich 500 Test-Benachrichtigungen zu einer Client-Adresse vom Staging. Die Kosten von „einfach" summieren sich schnell.

Es gibt auch die Konto-Verwaltungs-Überlastung. Ein neues Gmail-Konto für jede Test-Umgebung zu erstellen bedeutet, 2FA, App-Passwörter und Googles zunehmend aggressives Bot-Detection zu verwalten. Es ist zerbrechliche Infrastruktur, die auf einem Service aufgebaut ist, der nicht für diesen Anwendungsfall konzipiert wurde.

2. Email-Sandboxes

Tools wie Mailtrap fangen ausgehende E-Mail ab und zeigen sie in einem Dashboard. Ihre App denkt, sie sendet echte E-Mail, aber nichts wird tatsächlich zugestellt.

Sandboxes sind nützlich zum Überprüfen von HTML-Templates und zum Abfangen versehentlicher Sends. Aber sie können echte Zustellung nicht testen. Sie können nicht überprüfen, dass eine E-Mail tatsächlich in einem Posteingang ankommt, von einem IMAP-Client korrekt geparst wird oder einen Webhook auslöst. Für End-zu-End-Tests sind Sandboxes unvollständig.

Es gibt auch die Protokoll-Lücke. Sandboxes geben Ihnen SMTP (zum Versenden), aber nicht IMAP (zum Lesen). Ihre Tests können feststellen, dass eine E-Mail von der Sandbox erfasst wurde, aber sie können nicht den vollständigen Abruf-Flow testen, den Ihr Produktions-Code verwendet. Lesen Sie mehr über diesen Kompromiss in unserem SMTP-Testing-Guide.

3. On-Demand echte Posteingänge

Der dritte Ansatz ist das programmgesteuerte Erstellen von echten E-Mail-Posteingängen – Posteingängen mit echten IMAP- und SMTP-Credentials, die echte E-Mail senden und empfangen. Das gibt Ihnen vollständige End-zu-End-Abdeckung ohne die Risiken der Verwendung persönlicher Konten.

Das ist das, was verwaltete Posteingänge von Reusable.Email bieten. Jeder verwaltete Posteingang ist ein vollständiges E-Mail-Konto mit IMAP-, SMTP- und POP3-Zugang. Sie erstellen ihn, verwenden ihn in Ihren Tests oder Produkten, und er funktioniert mit jeder E-Mail-Bibliothek in jeder Sprache.

Der Schlüssel-Vorteil ist Protokoll-Kompatibilität. Da verwaltete Posteingänge Standard-IMAP und SMTP verwenden, verwenden Ihr Test-Code und Ihr Produktions-Code die gleichen Bibliotheken, die gleichen Verbindungs-Patterns und das gleiche Error-Handling. Es gibt keine Test-nur Abstraktions-Schicht, die echtes Verhalten versteckt.

Reusable.Email für Entwickler

Ein verwalteter Posteingang auf Reusable.Email kostet $3 einmalig – nicht monatlich, nicht pro-Seat, nicht nutzungsbasiert. Diese $3 bekommen Sie:

• IMAP-Zugang bei imap.reusable.email:993 (SSL/TLS)
• SMTP-Zugang bei smtp.reusable.email:587 (STARTTLS)
• POP3-Zugang für Clients, die es bevorzugen
• 365-Tage E-Mail-Aufbewahrung
• Benutzerdefinierte Ordner, Spam-Filterung, Weiterleitung, Senden/Antwort
• Funktioniert mit Apple Mail, Thunderbird, Outlook oder jeder Standard-Bibliothek

Für Teams, die Produkte auf E-Mail aufbauen, fügt der Whitelabel-Tier ($30/Monat) eine REST API, Webhooks für Email-Ereignisse, ein Admin-Panel und null Reusable.Email-Branding hinzu. Mehr dazu im White-Label-Email-Service-Guide.

Use-Case 1: Email-Testen und QA

Automatisierte Tests, die E-Mail betreffen, müssen typischerweise:

1. Einen neuen Posteingang für den Test-Lauf erstellen
2. Eine Aktion auslösen, die E-Mail sendet (Anmeldung, Passwort-Zurückstellung, Benachrichtigung)
3. Den Posteingang lesen und den E-Mail-Inhalt überprüfen
4. Aufräumen

Mit verwalteten Posteingängen bekommt jede Test-Suite (oder sogar jeder Test) seinen eigenen echten Posteingang. Da der Posteingang Standard-IMAP unterstützt, lesen Sie Nachrichten mit jeder IMAP-Bibliothek – kein proprietäres SDK erforderlich.

Der Testing-Workflow sieht so aus: Ihre CI-Pipeline startet, Ihr Test-Code verbindet sich mit einem verwalteten Posteingang via IMAP, Ihre getestete Anwendung sendet eine E-Mail (Passwort-Zurückstellung, Willkommens-Email, Benachrichtigung), und Ihr Test-Code fragt den IMAP-Posteingang so lange ab, bis die E-Mail ankommt. Dann parsen Sie die E-Mail, überprüfen ihren Inhalt (richtiger Subject, richtiger Body, richtige Links) und fahren fort. Wenn die E-Mail nicht innerhalb eines Timeouts ankommt, schlägt der Test fehl – was genau das ist, was passieren sollte, wenn Ihre Email-Pipeline kaputt ist.

Das Kostenmodell macht das praktisch. Zehn permanente Test-Posteingänge kosten $30 insgesamt, einmalig. Vergleichen Sie das mit Mailtrap's $15-35/Monat oder Mailinator's Pro-Seat-Preisgestaltung. Über ein Jahr ist der Unterschied erheblich.

Für eine detaillierte Implementierungs-Anleitung mit Python- und Node.js-Code siehe Wie Sie eine Email-Testing-Umgebung mit einer Disposable-Email-API bauen.

Use-Case 2: Staging-Umgebungen

Staging-Umgebungen brauchen E-Mail, die wie Produktion funktioniert, aber isoliert bleibt. Die Anforderungen:

• Ausgehende E-Mail vom Staging sollte niemals echte Benutzer erreichen
• Entwickler müssen überprüfen, was gesendet wurde
• Idealerweise können Sie den vollständigen Senden-Empfangen-Loop testen

Ein verwalteter Posteingang pro Staging-Umgebung löst das. Konfigurieren Sie Ihre Staging-App zum Versenden über smtp.reusable.email:587 mit den Credentials dieses Posteingangs. Ausgehende E-Mail geht an einen echten Posteingang, den Sie kontrollieren. Sie können ihn via IMAP lesen, weiterleiten oder einfach die Weboberfläche überprüfen.

Da die SMTP-Credentials auf einen spezifischen verwalteten Posteingang begrenzt sind, gibt es kein Risiko, dass Staging-E-Mail zu Produktions-Adressen durchsickert. Der Posteingang ist von Design her isoliert.

Ein typisches Setup für ein Team mit mehreren Umgebungen:

• [email protected] – lokale Entwicklung, teilt sich das Team
• [email protected] – Staging-Umgebung, überprüft vor Deploys
• [email protected] – QA-Testen, verwendet vom Test-Team
• [email protected] – CI-Pipeline, verwendet in automatisierten Tests

Vier Posteingänge, $12 insgesamt, permanent. Der E-Mail jeder Umgebung ist vollständig von anderen isoliert.

Use-Case 3: Pro-Benutzer-Posteingänge in Ihrer SaaS-App

Manche Produkte müssen Benutzern ihre eigene E-Mail-Adresse geben. Ticketing-Systeme, Customer-Service-Plattformen, CRM-Tools, Projektmanagement-Apps – alle profitieren davon, Benutzern zu erlauben, E-Mail direkt ins Produkt zu empfangen.

Der traditionelle Ansatz ist das Betreiben Ihres eigenen Mail-Servers. Postfix, Dovecot, DNS-Einträge, Spam-Filterung, Zustellbarkeits-Überwachung, Speicherverwaltung. Es ist ein Vollzeit-Job.

Mit Reusable.Email erstellen Sie einen verwalteten Posteingang für jeden Benutzer. Sie bekommen echte IMAP/SMTP-Credentials. Ihre App verbindet sich via IMAP, um Nachrichten zu ziehen, oder verwendet Webhooks (Whitelabel-Tier) für Echtzeit-Benachrichtigungen. Der Benutzer sieht E-Mail innerhalb Ihres Produkts; Sie berühren niemals einen Mail-Server.

Bei $3 pro Posteingang kostet das Geben von 1.000 Benutzern ihre eigene E-Mail-Adresse $3.000 – einmalig. Keine monatlichen Skalierungs-Kosten. Lesen Sie die vollständige Architektur im On-Demand SMTP & IMAP-Credentials.

Use-Case 4: Ein Temp-Mail-Produkt bauen

Wenn Sie einen Temp-Mail-Service, ein Datenschutz-Tool oder ein Produkt bauen, bei dem disposable Posteingänge die Kern-Funktion sind, ist der Whitelabel-Tier für das konzipiert.

Für $30/Monat bekommen Sie:

• Unbegrenzte verwaltete Posteingänge auf Ihrer Domain
• Null Reusable.Email-Branding
• Vollständige REST API für Posteingangs-Erstellung und Management
• Webhooks für Echtzeit-Email-Ereignisse
• Usage-Analytics-Dashboard
• Admin-Panel zur Verwaltung von Konten und Domains

Ihre Benutzer sehen Ihre Marke. Die Infrastruktur wird gehandhabt. Sie konzentrieren sich auf das Produkt. Lesen Sie den vollständigen Überblick im White-Label-Email-Service-Guide.

Protokoll-Referenz: IMAP, SMTP und POP3

Bevor wir in Code gehen, hier ist eine schnelle Referenz zum Verbinden mit verwalteten Reusable.Email-Posteingängen.

Protokoll	Host	Port	Verschlüsselung	Zweck
IMAP	imap.reusable.email	993	SSL/TLS	E-Mail lesen, suchen, Ordner verwalten
SMTP	smtp.reusable.email	587	STARTTLS	E-Mail versenden
POP3	pop.reusable.email	995	SSL/TLS	E-Mail herunterladen (Alternative zu IMAP)

Authentifizierung für alle Protokolle verwendet die E-Mail-Adresse des Posteingangs als Benutzername und das Posteingangs-Passwort. Kein OAuth2, keine App-spezifischen Passwörter, keine API-Keys. Standard-Credentials, die mit jeder E-Mail-Bibliothek funktionieren.

IMAP vs POP3: IMAP hält Nachrichten auf dem Server und unterstützt Ordner, Suche und Flags. POP3 lädt Nachrichten herunter und (standardmäßig) entfernt sie vom Server. Für programmgesteuerten Zugang ist IMAP fast immer die bessere Wahl – es lässt Sie Suchen, Filtern und Status Server-seitig verwalten.

IMAP-Integration: E-Mails programmgesteuert lesen

Jeder verwaltete Posteingang unterstützt IMAP bei imap.reusable.email:993 mit SSL/TLS. Hier ist, wie man verbindet und Nachrichten in Python liest:

import imaplib
import email
from email.header import decode_header

# Verbindung zum Reusable.Email IMAP-Server
imap = imaplib.IMAP4_SSL("imap.reusable.email", 993)
imap.login("[email protected]", "your-password")

# Posteingang auswählen
imap.select("INBOX")

# Suche nach allen ungelesenen Nachrichten
status, messages = imap.search(None, "UNSEEN")
message_ids = messages[0].split()

for msg_id in message_ids:
    # E-Mail abrufen
    status, msg_data = imap.fetch(msg_id, "(RFC822)")
    raw_email = msg_data[0][1]

    # E-Mail parsen
    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}")

    # E-Mail-Body abrufen
    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()

Das ist Standard-imaplib – kein proprietäres SDK, kein Vendor Lock-in. Jede IMAP-Bibliothek in jeder Sprache funktioniert auf die gleiche Weise.

Warten auf E-Mail in Tests

In automatisierten Tests müssen Sie oft darauf warten, dass eine E-Mail ankommt. Hier ist ein Polling-Pattern:

import time

def wait_for_email(imap, subject_contains, timeout=30, interval=2):
    """Poll IMAP inbox until an email matching the subject arrives."""
    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")

Für Echtzeit-Zustellung ohne Polling senden Whitelabel-Tier-Webhooks Ereignisse an Ihren Endpoint in dem Moment, in dem eine E-Mail ankommt. Mehr dazu im Wie man E-Mails via API empfängt.

SMTP-Integration: E-Mails programmgesteuert versenden

Jeder verwaltete Posteingang hat auch SMTP-Zugang bei smtp.reusable.email:587 mit STARTTLS. Hier ist ein Node.js-Beispiel mit 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();

Da das Standard-SMTP ist, funktioniert der gleiche Ansatz mit jeder Sprache: Pythons smtplib, Rubys Net::SMTP, Gos net/smtp, PHP's PHPMailer, Javas Jakarta Mail.

Python SMTP-Beispiel

Für Vollständigkeit, hier ist das Python-Äquivalent mit 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>",
)

Versenden mit Anhängen

Das Hinzufügen von Anhängen folgt dem Standard-MIME-Ansatz:

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)

Nichts hier ist Reusable.Email-spezifisch. Das ist der gleiche Code, den Sie für jeden SMTP-Server schreiben würden. Das ist der Punkt – kein Vendor Lock-in, kein proprietäres SDK zum Lernen und Warten.

Webhooks: Echtzeit-Email-Ereignisse

Der Whitelabel-Tier unterstützt Webhooks, die Ihre Anwendung benachrichtigen, wenn E-Mail-Ereignisse auftreten. Wenn eine E-Mail bei einem verwalteten Posteingang unter Ihrer Domain ankommt, sendet Reusable.Email ein HTTP POST zu Ihrem konfigurierten Endpoint mit den Nachrichtendetails.

Das ist der Ansatz für Produkte, die Echtzeit-Email-Verarbeitung brauchen – keine Polling-Verzögerung, keine persistenten IMAP-Verbindungen, keine verpassten Nachrichten.

Typisches Webhook-Payload umfasst:

• Absender, Empfänger, Subject
• Plain-Text- und HTML-Body
• Anhang-Metadaten
• Zustellungs-Zeitstempel

Ihr Endpoint empfängt das Ereignis, verarbeitet es (extrahieren von Verifizierungs-Codes, Routen zum richtigen Benutzer, Auslösen von Anwendungslogik) und antwortet mit einem 200-Status.

Für einen vollständigen Vergleich von IMAP-Polling vs. Webhooks vs. API-Polling, siehe Wie man E-Mails via API empfängt.

Sicherheits-Überlegungen

Wenn Sie Email-Credentials in Entwicklung, Testen und Produktion verwenden, gelten Standard-Sicherheits-Praktiken:

Lagern Sie Credentials in Umgebungs-Variablen oder einem Secrets-Manager. Kodieren Sie Posteingangs-Passwörter niemals fest in Source-Code. Verwenden Sie Ihres CI-Plattform's Secrets-Verwaltung (GitHub Actions-Secrets, GitLab CI-Variablen, usw.) für automatisierte Pipelines.

Verwenden Sie separate Posteingänge pro Umgebung. Teilen Sie nicht den gleichen verwalteten Posteingang zwischen Entwicklung, Staging und Produktion. Isolation verhindert Cross-Umgebungs-Verunreinigung und begrenzt den Blast-Radius kompromittierter Credentials.

Rotieren Sie Passwörter, wenn kompromittiert. Wenn ein Posteingangs-Passwort versehentlich zu einem öffentlichen Repository committed wird, ändern Sie es sofort über die Reusable.Email-Oberfläche.

TLS überall. Sowohl IMAP (Port 993, SSL/TLS) als auch SMTP (Port 587, STARTTLS) verwenden verschlüsselte Verbindungen. Ihr Email-Inhalt und Ihre Credentials werden niemals im Klartext übertragen.

Preismodell für Entwickler

Die meisten Email-Test- und API-Services berechnen monatliche Pro-Seat-Gebühren. Hier ist, wie Reusable.Email vergleicht:

Service	Preismodell	Kosten für 10 Posteingänge/Jahr
Reusable.Email	$3/Posteingang einmalig	$30 (einmalig)
Mailtrap	$15-35/Monat	$180-420/Jahr
Mailinator	Pro-Seat-Abo	$200+/Jahr
Mailosaur	Pro-Seat-Abo	$300+/Jahr

Die einmalige Preisgestaltung bedeutet, dass Ihre Email-Infrastruktur-Kosten vorhersehbar sind und nicht mit Teamgröße oder Zeit skalieren. Ein Startup und ein 50-köpfiges Team zahlen das Gleiche pro Posteingang.

Für Teams, die die vollständige API- und Webhook-Infrastruktur brauchen, umfasst der Whitelabel-Tier bei $30/Monat unbegrenzte verwaltete Posteingänge – die Kosten pro Posteingang fallen auf Null, sobald Sie auf diesem Plan sind.

FAQ

Wie erstelle ich Posteingänge programmgesteuert?

Auf dem Whitelabel-Tier verwenden Sie die REST API zum Erstellen verwalteter Posteingänge. Jeder Posteingang bekommt eigene IMAP/SMTP-Credentials. Für kleinere Skala können Sie verwaltete Posteingänge über die Reusable.Email-Weboberfläche erstellen und die Credentials in Ihrem Code verwenden.

Welche Protokolle unterstützt Reusable.Email?

Alle verwalteten Posteingänge unterstützen IMAP (Port 993, SSL/TLS), SMTP (Port 587, STARTTLS) und POP3. Das sind Standard-Protokolle, die mit jeder E-Mail-Bibliothek oder -Client funktionieren.

Kann ich E-Mails via Webhook empfangen?

Ja, auf dem Whitelabel-Tier. Webhooks senden ein HTTP POST zu Ihrem Endpoint, wenn E-Mail bei einem verwalteten Posteingang unter Ihrer Domain ankommt. Für andere Tiers verwenden Sie IMAP-Polling. Lesen Sie den Email-Empfangs-API-Guide für Implementierungs-Details.

Wie viel kostet es, 100 Test-Posteingänge zu erstellen?

$300, einmalig. Das sind 100 verwaltete Posteingänge bei $3 je. Keine monatlichen Gebühren, keine Verlängerung. Wenn Sie mehr als ~10 Posteingänge brauchen, wird der Whitelabel-Tier bei $30/Monat mit unbegrenzter Posteingangs-Erstellung via API billiger im Maßstab.

Gibt es eine offizielle API?

Der Whitelabel-Tier umfasst eine vollständige REST API zum Erstellen und Verwalten von Posteingängen, Domains und Konten. Für den Standard-Managed-Posteingang-Tier interagieren Sie über Standard-IMAP/SMTP-Protokolle – die sind selbst eine API, die jede Programmiersprache nativ unterstützt.

Kann ich Reusable.Email mit meiner bestehenden E-Mail-Bibliothek verwenden?

Ja. Jede Bibliothek, die IMAP und SMTP unterstützt, funktioniert sofort. Das umfasst Pythons imaplib und smtplib, Node.js's nodemailer und imapflow, Rubys net/imap und net/smtp, Gos net/smtp, PHP's PHPMailer, Javas Jakarta Mail und viele mehr. Kein SDK zum Installieren.

Wie lange werden E-Mails aufbewahrt?

Verwaltete Posteingänge behalten E-Mail für 365 Tage. Danach werden Nachrichten automatisch gelöscht. Wenn Sie längere Aufbewahrung brauchen, ziehen Sie Nachrichten via IMAP in Ihren eigenen Storage.

Kann ich eine benutzerdefinierte Domain verwenden?

Ja. Benutzerdefinierte Domains ($10/Jahr) lassen Sie Posteingänge bei [email protected] erstellen. Der Whitelabel-Tier umfasst benutzerdefinierte Domain-Unterstützung mit Auto-konfiguriertem MX, SPF, DKIM und DMARC.

Fazit

Email in der Entwicklung braucht nicht kompliziert oder teuer zu sein. Standard-Protokolle – IMAP und SMTP – sind seit Jahrzehnten das Rückgrat von E-Mail, und sie funktionieren mit jeder Sprache und jedem Framework.

Reusable.Email gibt Entwicklern echte Posteingänge mit echten Credentials zu einmaligen Kosten. Keine Sandbox-Limitierungen, keine Abonnement-Laufbahn, keine proprietären SDKs. Für Teams, die Produkte auf E-Mail bauen, fügt der Whitelabel-Tier die API-Ebene und Webhooks hinzu, die für Produktion nötig sind.

Egal ob Sie Tests schreiben, Staging isolieren, Benutzern ihren eigenen Posteingang geben oder den nächsten Temp-Mail-Service bauen – die Infrastruktur ist die gleiche: einen Posteingang erstellen, Credentials abrufen, mit Standard-Protokollen verbinden.