Resend-kompatible E-Mail-APIs: Was Kompatibilität nicht abdeckt

Was API-Kompatibilität tatsächlich bedeutet

For email developers, Resend-compatible mail APIs implement the same request and response schemas as the provider they replace. If you use a Resend-compatible API, you can change your base URL and API key in your environment variables and your POST /emails calls will still work. It covers the syntax of the payload, the HTTP status codes, and the structure of the JSON response. It does not cover your sender reputation, your DNS configuration, your IP warm up, or your billing structure.

Als Entwickler, der die Incident-Warteschlange verantwortet, habe ich erlebt, wie Teams „Kompatibilität“ für eine Migration per Mausklick halten. Das ist sie nicht. Sie migrieren die Schnittstelle, nicht die Infrastruktur.

Die Schnittstelle: Was abgedeckt ist

Wenn ein Provider Kompatibilität mit Resend verspricht, bildet er in der Regel den zentralen Versand-Endpunkt nach. So können Sie einen Payload wie diesen senden:

{ "from": "onboarding@example.com", "to": "user@gmail.com", "subject": "Welcome to the App", "html": "<strong>Hello!</strong>" }

Ist die API kompatibel, gibt der Server 200 OK oder 201 Created mit einer Nachrichten-ID zurück. Das ist der „einfache“ Teil. Sie müssen weder Ihre Integrationslogik neu schreiben noch Ihre SDKs wechseln. Für Teams, die KI-Agenten bauen, ist diese Konsistenz entscheidend. Wenn Agenten E-Mails über einen MCP-Server oder eine A2A-Card auslösen, verlassen sie sich auf vorhersagbare Schemas, um zu prüfen, ob der Seiteneffekt (der E-Mail-Versand) tatsächlich eingetreten ist.

Die Infrastruktur: Was NICHT abgedeckt ist

Die Kompatibilität endet an der HTTP-Schicht. Alles, was nach der Annahme der Anfrage durch die API geschieht, ist providerspezifisch.

1. DNS und Domain-Verifizierung

Ihr API-Schlüssel trägt keine Autorisierung für Ihre Domain. Sie können nicht einfach die URL wechseln und erwarten, dass Ihre E-Mails authentifiziert sind. Sie müssen Ihre Domain beim neuen Provider erneut verifizieren. Dazu fügen Sie neue SPF-, DKIM- und DMARC-Einträge zu Ihrem DNS hinzu.

Wenn Sie vergessen, diese zu aktualisieren, werden Ihre E-Mails wahrscheinlich abgelehnt oder als Spam markiert, weil der neue Provider nicht berechtigt ist, in Ihrem Namen zu senden. Mit dem SendHQ E-Mail-DNS-Checker können Sie prüfen, ob Ihre Einträge korrekt propagiert sind, bevor Sie umschalten.

2. Absenderreputation und IP-Warm-up

Die Reputation hängt an der sendenden IP und an der Domain. Wenn Sie von einem Provider zu einem anderen wechseln, wechseln Sie oft zu einem neuen Satz von Shared IPs. Selbst wenn Ihre Domain eine hervorragende Reputation hat, kann die neue IP „kalt“ sein oder – schlimmer – mit einem schlechten Akteur geteilt werden.

Die Annahme durch den Provider (die API sagt „OK“) ist etwas anderes als die Zustellung (der empfangende Server nimmt die E-Mail an), und diese wiederum etwas anderes als die Platzierung im Posteingang (die E-Mail landet im Hauptordner). Kompatibilität deckt die Annahme durch den Provider ab. Für Zustellung oder Platzierung bewirkt sie nichts.

3. Webhooks und Event-Schemas

Auch wenn die Versand-API kompatibel ist, sind es die Webhook-Events (delivered, bounced, complained) oft nicht. Wenn Ihr System Zustell-Events auswertet, um Folgelogik auszulösen, müssen Sie die Webhook-Payloads des neuen Providers prüfen. Ein bounce-Event im einen System kann im anderen ein hard_bounce sein.

Was Kompatibilität kostet: die Preisrealität

Kompatibilität ermöglicht es Ihnen, nach besseren Preisen zu suchen, ohne die Kosten einer kompletten Neuentwicklung. Die Preismodelle unterscheiden sich allerdings enorm. Auf Basis der Daten vom September 2026:

• Amazon SES: Die aggressivsten Preise. A la carte kostet 0.10 USD pro 1.000 E-Mails (Amazon-SES-Preise). Die am 21. Juli 2026 eingeführten Stufentarife umfassen Essentials (0.16 USD pro 1.000), Pro (0.22 USD pro 1.000 plus 105 USD pro Monat und Region) und Enterprise (0.23 USD pro 1.000 plus 500 USD pro Monat).
• Resend: Bietet einen kostenlosen Tarif mit 3.000 E-Mails pro Monat (maximal 100 pro Tag). Der Pro-Tarif kostet 20 USD pro Monat für 50.000 E-Mails, Mehrkosten 0.90 USD pro 1.000 (Resend-Preise).
• Postmark: 15 USD pro Monat für 10.000 E-Mails, Mehrkosten zwischen 1.80 und 1.20 USD pro 1.000 (Postmark-Preise).
• Mailgun: 15 USD pro Monat für 10.000 E-Mails, Mehrkosten zwischen 1.80 und 1.10 USD pro 1.000 (Mailgun-Preise).
• SendGrid: Der kostenlose Tarif ist jetzt eine 60-tägige Testphase, Essentials beginnt bei 19.95 USD pro Monat (SendGrid-Preise).

Zur Einordnung: Der Versand von 50.000 E-Mails kostet mit SES A la carte etwa 5 USD, bei den Postmark-Stufen dagegen etwa 66 USD. API-Kompatibilität macht diese Kostenoptimierung möglich, ohne einen Monat Entwicklungsarbeit.

Zuverlässigkeit und Agenten technisch absichern

Wenn Sie E-Mail als externen Seiteneffekt behandeln – besonders beim Einsatz von KI-Agenten –, müssen Sie mit Fehlern rechnen. Eine API, die 200 OK zurückgibt, bedeutet nicht, dass die E-Mail den Nutzer erreicht hat.

Idempotenz

Wiederholt ein Agent eine Anfrage nach einem Timeout, riskieren Sie, dieselbe E-Mail zweimal zu senden. Das ist ein schlechtes Nutzererlebnis. Verwenden Sie einen Idempotenzschlüssel in Ihren Headern. So sendet der Provider nur eine E-Mail, auch wenn dieselbe Anfrage zweimal eintrifft.

Freigabe-Workflows

Agenten sollten keinen uneingeschränkten Zugriff auf Ihr Versandkontingent haben. Richten Sie für Sendungen mit hohem Volumen eine Freigabeschicht ein. Eine einfache Checkliste für agentengesteuerte E-Mails:

1. Schemavalidierung: Entspricht der Payload der Spezifikation der kompatiblen API?
2. Rate-Limiting: Überschreitet der Agent das Tageslimit (z. B. das kostenlose Limit von 100/Tag bei Resend)?
3. Idempotenz: Gibt es einen eindeutigen Schlüssel für genau diese Transaktion?
4. Human-in-the-Loop: Braucht diese E-Mail vor dem API-Aufruf eine manuelle Freigabe?

Migrations-Checkliste

Wenn Sie zu einem Resend-kompatiblen Provider wechseln, halten Sie diese Reihenfolge ein, um einen Einbruch der Zustellung zu vermeiden:

• DNS-Einrichtung: Konfigurieren Sie SPF, DKIM und DMARC. Lesen Sie unseren Leitfaden zur E-Mail-Authentifizierung, damit keine Einträge fehlen.
• Verifizierung: Bestätigen Sie die DNS-Propagierung mit einem Tool.
• Warm-up: Bei hohem Versandvolumen verschieben Sie den Traffic schrittweise vom alten zum neuen Provider. Verschieben Sie nicht 100 % des Traffics in einer Stunde.
• Webhook-Audit: Ordnen Sie die Event-Typen des neuen Providers Ihren internen Datenbankschemas zu.
• Fehlerbehandlung: Testen Sie, wie der neue Provider ungültige E-Mails behandelt. Gibt er 400 zurück oder 202 mit einem späteren Bounce-Event?

Die Abwägungen im Überblick

Merkmal | Durch Kompatibilität abgedeckt? | Erforderliche Maßnahme

Anfrage-Payload | Ja | Keine (bei passender Spezifikation)

Antwortformat | Ja | Keine (bei passender Spezifikation)

Domain-Authentifizierung | Nein | DNS-Einträge aktualisieren

IP-Reputation | Nein | Warm-up-Phase

Preise/Kontingente | Nein | Preisseiten der Anbieter prüfen

Webhook-Events | Nein | Event-Listener aktualisieren

Kompatibilität ist ein Werkzeug für Agilität, kein Zauberstab für die Zustellbarkeit. Wenn Sie die Schnittstelle von der Infrastruktur trennen, können Sie Kosten und Leistung optimieren, ohne sich an das Ökosystem eines einzelnen Anbieters zu binden.

Eine datensparsame, agentenfähige E-Mail-API, die diese Infrastruktur vereinfacht, finden Sie bei SendHQ.