Resend-compatibele e-mail-API's: wat compatibiliteit niet dekt

Wat API-compatibiliteit echt betekent

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 engineer die de incidentqueue beheert, heb ik teams zien aannemen dat "compatibiliteit" een migratie met één klik is. Dat is het niet. Je migreert de interface, niet de infrastructuur.

De interface: wat wordt gedekt

Wanneer een provider claimt compatibel te zijn met Resend, spiegelt hij doorgaans het belangrijkste verzendendpoint. Daardoor kun je een payload als deze versturen:

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

Is de API compatibel, dan retourneert de server een 200 OK of 201 Created met een bericht-ID. Dat is het "makkelijke" deel. Je hoeft je integratielogica niet te herschrijven of van SDK te wisselen. Voor teams die AI-agents bouwen is die consistentie essentieel. Wanneer agents e-mails versturen via een MCP-server of een A2A-card, vertrouwen ze op voorspelbare schema's om te verifiëren dat het neveneffect (het versturen van de e-mail) echt heeft plaatsgevonden.

De infrastructuur: wat NIET wordt gedekt

Compatibiliteit houdt op bij de HTTP-laag. Alles wat er gebeurt nadat de API de request heeft geaccepteerd, is providerspecifiek.

1. DNS en domeinverificatie

Je API-sleutel neemt de autorisatie voor je domein niet mee. Je kunt niet simpelweg van URL wisselen en verwachten dat je e-mails geauthenticeerd zijn. Je moet je domein opnieuw verifiëren bij de nieuwe provider. Daarvoor voeg je nieuwe SPF-, DKIM- en DMARC-records toe aan je DNS.

Vergeet je die bij te werken, dan worden je e-mails waarschijnlijk geweigerd of als spam gemarkeerd, omdat de nieuwe provider niet gemachtigd is om namens jou te verzenden. Met de E-mail-DNS-checker van SendHQ controleer je of je records correct zijn doorgevoerd voordat je overschakelt.

2. Afzenderreputatie en IP-warm-up

Reputatie is gekoppeld aan het verzend-IP en het domein. Stap je over naar een andere provider, dan kom je vaak op een nieuwe set gedeelde IP's terecht. Zelfs als je domein een uitstekende reputatie heeft, kan het nieuwe IP "koud" zijn, of erger: gedeeld met een kwaadwillende afzender.

Acceptatie door de provider (de API zegt "OK") is iets anders dan bezorging (de ontvangende server accepteert de e-mail), en dat is weer iets anders dan inboxplaatsing (de e-mail belandt in de hoofdmap). Compatibiliteit dekt acceptatie door de provider. Voor bezorging of plaatsing doet het niets.

3. Webhooks en eventschema's

De verzend-API is misschien compatibel, maar de webhook-events (delivered, bounced, complained) zijn dat vaak niet. Vertrouwt je systeem op het bijhouden van bezorgevents om vervolglogica te starten, dan moet je de webhookpayloads van de nieuwe provider controleren. Een bounce-event in het ene systeem kan in een ander systeem een hard_bounce zijn.

De prijs van compatibiliteit: de realiteit van de prijzen

Dankzij compatibiliteit kun je rondkijken voor betere prijzen zonder de kosten van een volledige herschrijving. De prijsmodellen lopen echter sterk uiteen. Op basis van gegevens uit september 2026:

• Amazon SES: de scherpste prijzen. A la carte kost 0.10 USD per 1.000 e-mails (prijzen van Amazon SES). De nieuwe abonnementsniveaus die op 21 juli 2026 zijn ingevoerd, zijn Essentials (0.16 USD per 1.000), Pro (0.22 USD per 1.000 plus 105 USD per maand per regio) en Enterprise (0.23 USD per 1.000 plus 500 USD per maand).
• Resend: biedt een gratis niveau van 3.000 e-mails per maand (met een maximum van 100 per dag). Het Pro-abonnement kost 20 USD per maand voor 50.000 e-mails, met overschrijdingen tegen 0.90 USD per 1.000 (prijzen van Resend).
• Postmark: 15 USD per maand voor 10.000 e-mails, met overschrijdingen tussen 1.80 en 1.20 USD per 1.000 (prijzen van Postmark).
• Mailgun: 15 USD per maand voor 10.000 e-mails, met overschrijdingen tussen 1.80 en 1.10 USD per 1.000 (prijzen van Mailgun).
• SendGrid: het gratis niveau is nu een proefperiode van 60 dagen en Essentials begint bij 19.95 USD per maand (prijzen van SendGrid).

Ter vergelijking: 50.000 e-mails versturen kost ongeveer 5 USD bij SES a la carte, maar ongeveer 66 USD bij de niveaus van Postmark. API-compatibiliteit maakt deze kostenoptimalisatie mogelijk zonder een maand engineeringwerk.

Engineering voor betrouwbaarheid en agents

Behandel je e-mail als een extern neveneffect, zeker bij het gebruik van AI-agents, dan moet je rekening houden met fouten. Een API die 200 OK retourneert, betekent niet dat de e-mail de gebruiker heeft bereikt.

Idempotentie

Probeert een agent een request opnieuw na een timeout, dan loop je het risico dat dezelfde e-mail twee keer wordt verstuurd. Dat is een slechte gebruikerservaring. Gebruik een idempotentiesleutel in je headers. Zo verstuurt de provider maar één e-mail, ook als dezelfde request twee keer binnenkomt.

Goedkeuringsworkflows

Agents horen geen onbeperkte toegang tot je verzendquotum te hebben. Implementeer een goedkeuringslaag voor verzendingen met een hoog volume. Een eenvoudige checklist voor e-mail die door agents wordt aangestuurd:

1. Schemavalidatie: komt de payload overeen met de specificatie van de compatibele API?
2. Rate limiting: overschrijdt de agent het daglimiet (bijv. de gratis limiet van 100 per dag bij Resend)?
3. Idempotentie: is er een unieke sleutel voor deze specifieke transactie?
4. Human-in-the-loop: moet deze e-mail handmatig worden goedgekeurd vóór de API-call?

Migratiechecklist

Stap je over naar een Resend-compatibele provider? Volg dan deze volgorde om te voorkomen dat je bezorging instort:

• DNS-configuratie: Configureer SPF, DKIM en DMARC. Lees onze gids over e-mailauthenticatie om te zorgen dat er geen records ontbreken.
• Verificatie: Gebruik een tool om DNS-propagatie te bevestigen.
• Warm-up: Bij grote volumes verplaats je verkeer geleidelijk van de oude provider naar de nieuwe. Verplaats niet 100% van het verkeer in één uur.
• Webhookaudit: Koppel de eventtypen van de nieuwe provider aan je interne databaseschema's.
• Foutafhandeling: Test hoe de nieuwe provider ongeldige e-mailadressen afhandelt. Geeft deze een 400 terug, of een 202 met later een bounce-event?

De afwegingen op een rij

Kenmerk | Gedekt door compatibiliteit? | Vereiste actie

Requestpayload | Ja | Geen (als de specificatie overeenkomt)

Responsformaat | Ja | Geen (als de specificatie overeenkomt)

Domeinauthenticatie | Nee | DNS-records bijwerken

IP-reputatie | Nee | Warm-upperiode

Prijzen/quota | Nee | Prijspagina's van leveranciers bekijken

Webhook-events | Nee | Eventlisteners bijwerken

Compatibiliteit is een middel voor wendbaarheid, geen toverstaf voor deliverability. Door de interface los te zien van de infrastructuur kun je optimaliseren op kosten en prestaties zonder jezelf vast te leggen op het ecosysteem van één leverancier.

Zoek je een privacyvriendelijke e-mail-API die klaar is voor agents en deze infrastructuur eenvoudiger maakt? Ontdek dan SendHQ.