Eine Temp-Mail-Website vs eine Temp-Mail-API
Eine Temp-Mail-Website ist das, was du schon kennst: Seite öffnen, Wegwerf-Inbox bekommen, die Mail im Browser lesen. Ein Mensch ist die ganze Zeit beteiligt.
Eine Temp-Mail-API ist dieselbe Wegwerf-Postfach-Idee, nur als HTTP-Endpunkte bereitgestellt — sodass ein Programm das übernimmt statt eines Menschen. Dein Code fragt eine frische Adresse an, dein Code liest die eingehenden Nachrichten, dein Code wirft das Postfach weg — kein Browser, kein Klicken.
Dieser eine Unterschied — Code statt Mensch — macht es nützlich, und er grenzt zugleich ein, wer tatsächlich eine braucht.
Wer eine braucht
Drei Gruppen, grob absteigend:
- QA- und CI-Pipelines. Das ist der große Use-Case. Automatisierte Tests, die einen echten Signup-, E-Mail-Verifizierungs- oder Passwort-Reset-Flow durchspielen, brauchen ein Postfach, das existiert, Mails empfängt und nicht mit anderen Test-Runs kollidiert. Eine Temp-Mail-API gibt jedem Test-Run sein eigenes frisches Postfach. Dafür haben wir eine Schritt-für-Schritt-Anleitung mit Playwright geschrieben.
- Automatisierung und Tooling. Alles, was programmatisch Accounts registriert, einen Bestätigungslink ausliest oder die Zustellbarkeit der eigenen Transaktionsmails überwacht. Wenn ein Skript eine Nachricht empfangen muss, ist eine Temp-Mail-API der Weg dahin — ohne echtes Postfach.
- Entwickler beim Prototyping. Du baust einen Onboarding-Flow und willst die Verifizierungsmail ankommen sehen, ohne ein persönliches Postfach oder einen schwergewichtigen lokalen Mailserver (Mailpit, MailHog) zu verdrahten. Ein API-Call ist schneller als das Konfigurieren eines Services.
Wenn du jetzt nur eine Inbox für eine Anmeldung brauchst, brauchst du keine API — nimm die Website. Die API verdient ihren Platz in dem Moment, in dem die Aufgabe sich wiederholt oder unbeaufsichtigt laufen muss.
Dein erster Call gegen die Mailiy-API
Die Mailiy-REST-API liegt unter api.mailiy.com und nutzt Bearer-Token-Auth. Erzeuge einen Key in deinen Account-Settings (er beginnt mit ml_pk_) und lege ihn in einen Secret-Store, nicht ins Repo.
Postfach erstellen:
curl -X POST https://api.mailiy.com/v1/mailbox \
-H "Authorization: Bearer $MAILIY_API_KEY" \
-H "Content-Type: application/json" \
-d '{"ttlMinutes": 30}'
Du bekommst eine id und eine address zurück. Nutze die Adresse, wo du sie brauchst, und lies dann, was angekommen ist:
curl https://api.mailiy.com/v1/mailbox/$ID/messages \
-H "Authorization: Bearer $MAILIY_API_KEY"
Polle diesen Endpunkt in kurzem Intervall, bis messages nicht leer ist — Mail erscheint in der Regel in unter einer Sekunde nach dem SMTP-Eingang. Wenn du fertig bist, räume mit DELETE /v1/mailbox/:id auf — oder lass die TTL es ablaufen.
Das ist die gesamte Kern-API: erstellen, lesen, löschen. Es gibt zusätzlich POST /v1/webhooks, falls du eingehende Mail lieber gepusht bekommst, statt zu pollen.
Was es kostet
Die API ist pro Tarif gestaffelt — und der Free-Tier ist wirklich brauchbar, kein Teaser:
| Tier | Calls/Monat | Rate |
|---|---|---|
| api_free | 500 | 10 req/min |
| api_lite | 10.000 | 60 req/min |
| api_pro | 100.000 | 300 req/min |
Eine typische PR-Pipeline verbraucht 3–5 Calls pro Test (Create, Poll, optional Delete). Bei 50 Tests sind das ein paar hundert Calls pro Run — der Free-Tier deckt eine kleine CI-Suite komplett ab, api_pro eine ernsthafte. Business geht auf 1.000 req/min, Enterprise ist unbegrenzt.
Kurz gesagt
Eine Temp-Mail-API ist Wegwerf-Mail für Programme statt für Menschen. Ist deine Aufgabe einmalig und manuell, reicht die Website. Wiederholt sie sich, läuft sie im CI oder muss sie unbeaufsichtigt funktionieren, ist die API der Punkt — und du kannst deinen ersten Call gegen die Mailiy-API heute auf dem Free-Tier machen, ohne Kreditkarte.
Jetzt ausprobieren → Wegwerf-Adresse auf der mailiy-Startseite generieren — ein Klick, in unter zwei Sekunden bereit, keine Anmeldung, kein Account.