Temp Mail in Tests und CI integrieren

Die REST-API von Mail.td ist für End-to-End-Tests konzipiert — Verifizierung, dass Anmeldungen, Passwort-Resets und E-Mail-getriggerte Workflows korrekt funktionieren. Dieser Leitfaden konzentriert sich auf Integrationsmuster für gängige Test-Tools.

Für die rohe Endpoint-Referenz (Request/Response-Formate) siehe die API-Seite oder docs.mail.td.

Selenium / Playwright / Cypress

Das Muster: vor jedem Test ein neues Postfach erzeugen, deine App mit dieser Adresse anmelden und dann die API auf die Bestätigungs-E-Mail abfragen.

// Pseudocode — anpassbar an jedes Test-Framework
async function signUpFlow(page) {
  // 1. Temp-Postfach erstellen
  const mailbox = await fetch("https://api.mail.td/api/accounts", {
    method: "POST",
    headers: {
      Authorization: "Bearer td_xxx",
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      address: `test-${Date.now()}@mail.td`,
      password: "secret"
    })
  }).then(r => r.json());

  // 2. App mit mailbox.address anmelden
  await page.goto("/signup");
  await page.fill("[name=email]", mailbox.address);
  await page.click("button[type=submit]");

  // 3. Polling auf Bestätigungs-E-Mail (bis zu 30s)
  for (let i = 0; i < 30; i++) {
    const list = await fetch(
      `https://api.mail.td/api/accounts/${mailbox.id}/messages`,
      { headers: { Authorization: "Bearer td_xxx" } }
    ).then(r => r.json());
    if (list.messages.length > 0) {
      // Listen-Antwort hat keinen Body — Detail abrufen für text_body
      const msg = await fetch(
        `https://api.mail.td/api/accounts/${mailbox.id}/messages/${list.messages[0].id}`,
        { headers: { Authorization: "Bearer td_xxx" } }
      ).then(r => r.json());
      const link = extractLink(msg.text_body);
      await page.goto(link);
      break;
    }
    await new Promise(r => setTimeout(r, 1000));
  }
}

CI/CD-Pipelines

Für GitHub Actions, GitLab CI, CircleCI oder beliebige Pipelines:

  • Speichere ein API-Token als CI-Secret (rotiere es vom Dashboard, falls geleakt)
  • Jeder Test-Job erzeugt sein eigenes Postfach — vermeidet Race Conditions zwischen parallelen Jobs
  • Eindeutige Adresse pro Test (z. B. test-${RUN_ID}-${TEST_ID}@mail.td) — erleichtert Debugging
  • Kein Aufräumen nötig — Postfächer laufen automatisch ab, kein Cleanup-Skript nötig

Webhooks für schnellere Pipelines (Pro)

Polling fügt jedem Test Latenz hinzu. Für lange Test-Suiten registriere eine Webhook-URL, die einen POST bei eingehender Mail erhält. Dein Test wartet auf die Webhook-Zustellung statt 30 Mal zu pollen. Reduziert eine typische 5–15-Sekunden-Wartezeit auf unter 1 Sekunde.

Webhooks sind mit HMAC-SHA256 signiert — verifiziere den Signatur-Header vor der Verarbeitung.

SDK-Installation

npm install mailtd       # Node.js / TypeScript
pip install mailtd       # Python
go get github.com/mailtd/mailtd-go    # Go

Vollständige Endpoint-Referenz: mail.td/api.

Häufig gestellte Fragen

Wo bekomme ich ein API-Token?

Pro-Dashboard → API Tokens → Create. Tokens haben den Präfix `td_` und werden nur einmal bei der Erstellung angezeigt — kopiere und speichere sie in CI-Secrets oder einem Passwort-Manager.

Wie hoch ist das Rate Limit?

Free: 1 Anfrage/Sekunde; Pro: 10 Anfragen/Sekunde. Beim Erreichen des Limits gibt die API 429 mit `Retry-After`-Header zurück.

Wie funktionieren Webhook-Signaturen?

Jeder Webhook-POST enthält einen Signatur-Header, der aus deinem Webhook-Secret abgeleitet wird. Verifiziere die Signatur vor der Verarbeitung des Payloads, um zu bestätigen, dass die Anfrage von Mail.td stammt und nicht manipuliert wurde.

Kann ich End-to-End-Tests parallel laufen lassen?

Ja — gib jedem parallelen Test-Job sein eigenes Postfach, um Race Conditions zu vermeiden. Das Pro-Kontingent von 100 000 Ops/Monat deckt die meisten CI-Anwendungsfälle.

Funktioniert die API für Free-Konten?

Free umfasst 500 API-Operationen pro Monat — geeignet für leichtes Scripting. Für CI/CD oder höheren Durchsatz auf Pro upgraden: 100 000 Ops/Monat und höhere Anfragerate.