23 Jahre aus Stockholm
E-Mail-API · Ab €469/Monat

Email API — REST-API für event-getriebene Anwendungen

Eine HTTP/JSON-API mit feingranularen Webhooks für jeden Versand-Event: delivered, opened, clicked, bounced, complained, unsubscribed. Ideal für SaaS-Produkte mit event-getriebenen Workflows, Account-Lifecycle-Mails und Microservice-Architekturen, in denen Beobachtbarkeit auf Nachrichten-Ebene wichtig ist.

Was ist eine Email API?

Eine Email API ist ein HTTP/JSON-basierter Web-Service zur Versand-Abwicklung — als Alternative zum traditionellen SMTP-Protokoll. Statt einer SMTP-Konnektion mit ihren spezifischen Befehlen (HELO, MAIL FROM, RCPT TO, DATA, QUIT) führt Ihre Anwendung einen einfachen HTTP POST-Aufruf mit JSON-Payload aus. Der Antwort-Code zeigt Erfolg oder Fehler unmittelbar an, ohne komplexe Connection-State-Verwaltung.

Der entscheidende Unterschied zwischen API und SMTP liegt aber nicht in der Übertragung — sondern in der Beobachtbarkeit. Über Webhooks erfahren Sie in Echtzeit, was mit jeder einzelnen Nachricht geschieht: zugestellt (delivered), geöffnet (opened), angeklickt (clicked), zurückgewiesen (bounced), als Spam markiert (complained), abgemeldet (unsubscribed). Diese Beobachtbarkeit ist Voraussetzung für event-getriebene Workflows, in denen E-Mail-Versand integraler Bestandteil des Produkts ist.

Wann ist Email API die richtige Wahl?

Anwendungsfall 01

SaaS-Produkte mit event-getriebener Architektur

Ihr SaaS-Produkt sendet E-Mails als Reaktion auf Events: Nutzer-Registrierung, Aktion im Produkt, Erreichen von Meilensteinen. Sie benötigen Webhooks, um Events ans CRM, Analytics oder Customer-Success-Tools weiterzuleiten. Email API liefert diese Beobachtbarkeit nativ.

Anwendungsfall 02

Account-Lifecycle-E-Mails (Onboarding, Re-Engagement)

Onboarding-Sequenzen, Passwort-Reset-Mails, E-Mail-Verifikation, Re-Engagement-Kampagnen — alles event-getriebene Versendung mit Bedarf an Idempotency und granularer Beobachtbarkeit. Email API mit korrekter Idempotency-Keys verhindert doppelte Versendung.

Anwendungsfall 03

Marketing-Automation und Drip-Kampagnen

Drip-Sequenzen mit Abhängigkeit von Empfänger-Verhalten (z.B. „nächste Mail nur senden, wenn vorherige geöffnet wurde") brauchen Webhook-Daten in Echtzeit, um nächste Schritte zu triggern. SMTP allein liefert diese Daten nicht.

Anwendungsfall 04

Transaktions-E-Mails mit Tracking-Bedarf

Bestätigungen, Rechnungen, Versand-Updates — Sie wollen wissen, ob der Empfänger sie geöffnet hat (für Customer-Success-Outreach) und ob er auf den Tracking-Link geklickt hat. Email API liefert diese Daten als Webhook-Events.

Anwendungsfall 05

Microservices-Architektur mit Service-zu-Service-Kommunikation

In Microservices-Architekturen ist HTTP der natürliche Kommunikationsweg. Ein dedizierter Mailing-Microservice kann via API einfach in das bestehende Service-Mesh integriert werden, mit Zirkular-Nachverfolgung und konsistenter Observability.

Anwendungsfall 06

Mobile-Anwendungen ohne SMTP-Bibliothek

Mobile- und Frontend-Anwendungen können nicht direkt via SMTP versenden (Sicherheitsrisiko, Anti-Pattern). API-Aufrufe von Backend-Services oder via Backend-for-Frontend-Pattern sind der korrekte Ansatz. Email API ist die einzige praktikable Option für solche Architekturen.

API-Endpoints und Versand-Beispiel

Versand einer Nachricht

POST https://api.authorizehosting.com/v3/emails
Authorization: Bearer [Ihr API-Key]
Content-Type: application/json

{
  "from": {
    "email": "noreply@ihre-domain.de",
    "name": "Ihr Unternehmen"
  },
  "to": [{"email": "kunde@example.com", "name": "Kundenname"}],
  "reply_to": {"email": "support@ihre-domain.de"},
  "subject": "Ihre Bestellung wurde bestätigt",
  "html": "<p>Hallo Kundenname,</p>...",
  "text": "Hallo Kundenname, ...",
  "custom_args": {
    "event_type": "order_confirmation",
    "order_id": "ORD-12345",
    "customer_id": "CUST-678"
  },
  "categories": ["transactional", "order_lifecycle"],
  "headers": {
    "X-Idempotency-Key": "order-ORD-12345-v1"
  }
}

Erfolgreiche Antwort

HTTP 202 Accepted
{
  "message_id": "msg_abc123xyz789",
  "queued_at": "2026-04-25T08:30:15Z",
  "status": "queued"
}

Webhooks — die wichtigste Funktion

Webhooks sind das, was API-basierten Versand vom SMTP-Versand qualitativ unterscheidet. Sie konfigurieren eine HTTP-URL in Ihrem System, an die wir POST-Anfragen senden, sobald ein Event eintritt. Ihre Anwendung verarbeitet diese Events in Echtzeit für Datenbank-Updates, Trigger-Aktionen, Reporting an interne Stakeholder.

Webhook-Payload-Beispiel (delivered + opened)

POST https://ihre-anwendung.de/webhooks/email-events
Content-Type: application/json
X-Authorize-Signature: sha256=...

[
  {
    "event": "delivered",
    "timestamp": 1735689600,
    "email": "kunde@example.com",
    "message_id": "msg_abc123xyz789",
    "custom_args": {
      "event_type": "order_confirmation",
      "order_id": "ORD-12345",
      "customer_id": "CUST-678"
    }
  },
  {
    "event": "opened",
    "timestamp": 1735689780,
    "email": "kunde@example.com",
    "message_id": "msg_abc123xyz789",
    "user_agent": "Mozilla/5.0...",
    "ip": "203.0.113.45",
    "custom_args": { ... }
  }
]

Verfügbare Event-Typen

1
delivered

Nachricht wurde vom empfangenden MTA akzeptiert (250 OK)

2
opened

Empfänger hat die Nachricht geöffnet (Tracking-Pixel geladen)

3
clicked

Empfänger hat einen Link in der Nachricht angeklickt

4
bounced

Nachricht zurückgewiesen — hard oder soft je nach SMTP-Code

5
complained

Empfänger hat die Nachricht als Spam markiert (via FBL)

6
unsubscribed

Empfänger hat sich über List-Unsubscribe abgemeldet

Idempotency und Zuverlässigkeit

Account-Lifecycle-E-Mails — Passwort-Reset, Verifikation, 2FA-Codes — sind Kategorien, in denen Doppelversand inakzeptabel ist. Unsere API unterstützt Idempotency-Keys nativ: Sie übergeben einen eindeutigen Schlüssel pro Versand-Intent (nicht pro Versuch), und unsere Infrastruktur erkennt Wiederholungs-Anfragen mit gleichem Schlüssel und gibt die ursprüngliche Antwort zurück, ohne die Nachricht erneut zu versenden.

Beispiel-Pattern für robusten Versand:

def send_password_reset(user_id):
    idempotency_key = f"pwreset-{user_id}-{token_hash}"
    response = api.post(
        "/v3/emails",
        json={
            "from": {"email": "noreply@app.de"},
            "to": [{"email": user.email}],
            "subject": "Passwort zurücksetzen",
            "html": render_template(...)
        },
        headers={"X-Idempotency-Key": idempotency_key}
    )
    # Bei Wiederholungs-Aufruf mit gleichem Key:
    # Antwort enthält die ursprüngliche message_id, kein Doppelversand

SDK-Unterstützung und Beispiel-Code

Wir bieten offizielle SDKs für die gängigen Sprachen (Python, Node.js, PHP, Java, Go, Ruby). Alternativ funktioniert die API mit jedem HTTP-Client-Library Ihrer Wahl — die API folgt REST-Konventionen und gängigen JSON-Strukturen.

Python (mit offiziellem SDK)

from authorizehosting import Client

client = Client(api_key="...")
response = client.emails.send(
    to=[{"email": "kunde@example.com"}],
    from_={"email": "noreply@ihre-domain.de"},
    subject="Bestellung bestätigt",
    html="<p>...</p>"
)
print(response.message_id)

Node.js (mit offiziellem SDK)

const { Client } = require('@authorizehosting/sdk');
const client = new Client({ apiKey: '...' });

const response = await client.emails.send({
  to: [{ email: 'kunde@example.com' }],
  from: { email: 'noreply@ihre-domain.de' },
  subject: 'Bestellung bestätigt',
  html: '<p>...</p>'
});
console.log(response.messageId);

Häufige Fragen zur Email API

Was unterscheidet Ihre Email API von SendGrid oder Mailgun?

Funktional sind die APIs ähnlich — alle bieten REST-Endpunkte und Webhooks. Die Unterschiede liegen in der Pricing-Struktur (wir bündeln dedizierte IPs ohne Add-on-Kosten), Jurisdiktion (EU statt USA, keine CLOUD-Act-Risiken), Support-Modell (direkter Kontakt zum operativen Team in Deutsch statt Tier-1-Helpdesk), und der Tatsache, dass wir uns ausschließlich auf E-Mail-Infrastruktur spezialisieren statt All-in-One-Marketing-Plattformen anzubieten. Detaillierter Vergleich: vs. SendGrid, vs. Mailgun.

Wie verifiziere ich Webhook-Signaturen?

Jeder Webhook-Aufruf enthält einen X-Authorize-Signature-Header mit HMAC-SHA256-Signatur des Body, signiert mit Ihrem geheimen Webhook-Secret. Ihre Anwendung sollte die Signatur vor Verarbeitung jedes Webhooks verifizieren — ohne diese Prüfung könnte ein Angreifer falsche Events in Ihr System einschleusen. Code-Beispiele für die Verifikation in allen unterstützten Sprachen finden Sie in unserer Dokumentation.

Was ist die Rate-Limit der API?

Standard-Rate-Limit: 100 Requests/Sekunde im Starter-Tarif, 500 Requests/Sekunde im Pro-Tarif. Für Enterprise-Kunden mit Hochvolumen-Bedarf konfigurieren wir individuelle Limits ohne Aufpreis. Bei Überschreitung erhalten Sie HTTP 429 mit Retry-After-Header — Ihr Code sollte exponential backoff respektieren.

Können Webhooks doppelt zugestellt werden?

Ja, in seltenen Fällen kann ein Event zweimal an Ihren Webhook-Endpunkt zugestellt werden (at-least-once-Semantik). Ihr Code sollte daher idempotent sein: jeden Event mit einer eindeutigen ID (kombiniere message_id + event-Typ + timestamp) tracken, und doppelte Verarbeitung erkennen. Dies ist Standard-Pattern für event-getriebene Systeme.

Was passiert, wenn mein Webhook-Endpunkt nicht erreichbar ist?

Wir versuchen die Webhook-Zustellung mit exponential backoff: nach 30 Sek, 2 Min, 10 Min, 1 Std, 6 Std, 24 Std. Nach 7 Tagen ohne erfolgreiche Zustellung markieren wir den Event als fehlgeschlagen und stoppen Versuche. Sie können verpasste Events über die API in einem Zeitfenster von 30 Tagen abrufen und nachverarbeiten.

Wann ist SMTP-Relay die bessere Wahl als Email API?

SMTP-Relay ist die bessere Wahl, wenn Ihre Anwendung bereits SMTP-Versand etabliert hat (Bestandssysteme, ERPs, CMS-Plugins) oder wenn Sie keinen Bedarf an Webhooks haben. SMTP ist auch das einzige Protokoll, das mit jeder Software seit den 90ern funktioniert — Email API benötigt eine Anwendung, die HTTP-Calls absetzen kann. Detaillierter Vergleich: SMTP-Relay vs. Email API.

Möchten Sie API-Beispiel-Code für Ihren Stack?

In einem 30-45-minütigen Gespräch zeigen wir Ihnen konkrete Integrationsbeispiele für Ihre Sprache (Python, Node, PHP, Java, Go, Ruby), besprechen Ihre event-getriebene Architektur und schätzen den passenden Tarif basierend auf Volumen und Webhook-Anforderungen.