API email compatibili con Resend: cosa la compatibilità non copre

Cosa significa davvero compatibilità delle API

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.

Da ingegnere che gestisce la coda degli incidenti, ho visto team dare per scontato che "compatibilità" significhi migrazione con un clic. Non è così. Stai migrando l'interfaccia, non l'infrastruttura.

L'interfaccia: cosa è coperto

Quando un provider dichiara la compatibilità con Resend, di solito replica l'endpoint principale di invio. Questo ti permette di inviare un payload come questo:

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

Se l'API è compatibile, il server restituirà un 200 OK o un 201 Created con un ID del messaggio. Questa è la parte "facile". Ti evita di dover riscrivere la logica di integrazione o cambiare SDK. Per i team che costruiscono agenti AI questa coerenza è fondamentale. Quando gli agenti attivano email tramite un server MCP o una card A2A, si affidano a schemi prevedibili per verificare che l'effetto collaterale (l'invio dell'email) sia avvenuto davvero.

L'infrastruttura: cosa NON è coperto

La compatibilità finisce al livello HTTP. Tutto ciò che accade dopo che l'API ha accettato la richiesta dipende dal provider.

1. DNS e verifica del dominio

La tua chiave API non porta con sé l'autorizzazione del dominio. Non puoi limitarti a cambiare URL e aspettarti che le tue email siano autenticate. Devi verificare di nuovo il dominio con il nuovo provider, il che significa aggiungere nuovi record SPF, DKIM e DMARC al tuo DNS.

Se dimentichi di aggiornarli, le tue email verranno probabilmente rifiutate o segnalate come spam, perché il nuovo provider non è autorizzato a inviare per tuo conto. Puoi usare il controllo DNS email di SendHQ per verificare che i tuoi record si siano propagati correttamente prima di fare il passaggio.

2. Reputazione del mittente e warm-up degli IP

La reputazione è legata all'IP di invio e al dominio. Se passi da un provider a un altro, spesso passi a un nuovo gruppo di IP condivisi. Anche se il tuo dominio ha un'ottima reputazione, il nuovo IP potrebbe essere "freddo" o, peggio, condiviso con un malintenzionato.

L'accettazione da parte del provider (l'API che risponde "OK") è diversa dalla consegna (il server ricevente che accetta la posta), che a sua volta è diversa dall'arrivo in inbox (la posta che finisce nella cartella principale). La compatibilità copre l'accettazione da parte del provider. Non fa nulla per la consegna o per l'arrivo in inbox.

3. Webhook e schemi degli eventi

Anche se l'API di invio è compatibile, spesso gli eventi webhook (consegnato, bounce, segnalazione di spam) non lo sono. Se il tuo sistema si basa sul tracciamento degli eventi di consegna per attivare logiche successive, devi verificare i payload dei webhook del nuovo provider. Un evento bounce in un sistema potrebbe essere un hard_bounce in un altro.

Il costo della compatibilità: la realtà dei prezzi

La compatibilità ti permette di cercare prezzi migliori senza il costo di una riscrittura completa. I modelli di prezzo, però, variano enormemente. In base ai dati di settembre 2026:

• Amazon SES: il prezzo più aggressivo. A consumo costa 0.10 USD ogni 1.000 email (prezzi di Amazon SES). I nuovi piani a livelli introdotti il 21 luglio 2026 includono Essentials (0.16 USD ogni 1.000), Pro (0.22 USD ogni 1.000 più 105 USD al mese per regione) ed Enterprise (0.23 USD ogni 1.000 più 500 USD al mese).
• Resend: offre un piano gratuito da 3.000 email al mese (con un limite di 100 al giorno). Il piano Pro costa 20 USD al mese per 50.000 email, con eccedenze a 0.90 USD ogni 1.000 (prezzi di Resend).
• Postmark: 15 USD al mese per 10.000 email, con eccedenze tra 1.80 e 1.20 USD ogni 1.000 (prezzi di Postmark).
• Mailgun: 15 USD al mese per 10.000 email, con eccedenze tra 1.80 e 1.10 USD ogni 1.000 (prezzi di Mailgun).
• SendGrid: il piano gratuito ora è una prova di 60 giorni ed Essentials parte da 19.95 USD al mese (prezzi di SendGrid).

Per dare un'idea: inviare 50.000 email costa circa 5 USD con SES a consumo, ma circa 66 USD con i piani di Postmark. La compatibilità delle API rende possibile questa ottimizzazione dei costi senza un mese di lavoro di ingegneria.

Progettare per l'affidabilità e per gli agenti

Quando tratti l'email come un effetto collaterale esterno, soprattutto con gli agenti AI, devi mettere in conto gli errori. Un'API che restituisce 200 OK non significa che l'email abbia raggiunto l'utente.

Idempotenza

Se un agente ritenta una richiesta per un timeout, rischi di inviare la stessa email due volte, con una pessima esperienza per l'utente. Usa una chiave di idempotenza nelle intestazioni. Così, se la stessa richiesta viene inviata due volte, il provider invia una sola email.

Flussi di approvazione

Gli agenti non dovrebbero avere accesso illimitato alla tua quota di invio. Implementa un livello di approvazione per gli invii ad alto volume. Una semplice checklist per le email inviate da agenti:

1. Validazione dello schema: il payload rispetta la specifica dell'API compatibile?
2. Limite di frequenza: l'agente sta superando il tetto giornaliero (ad es. il limite gratuito di Resend di 100 al giorno)?
3. Idempotenza: esiste una chiave univoca per questa specifica transazione?
4. Human-in-the-loop: questa email richiede un'approvazione manuale prima della chiamata API?

Checklist di migrazione

Se stai passando a un provider compatibile con Resend, segui questa sequenza per evitare un crollo delle consegne:

• Configurazione DNS: configura SPF, DKIM e DMARC. Leggi la nostra guida all'autenticazione email per assicurarti di non aver omesso record.
• Verifica: usa uno strumento per confermare la propagazione DNS.
• Warm-up: se invii volumi elevati, sposta gradualmente il traffico dal vecchio provider a quello nuovo. Non spostare il 100% del traffico in un'ora.
• Audit dei webhook: mappa i tipi di evento del nuovo provider agli schemi del database interno.
• Gestione degli errori: verifica come il nuovo provider gestisce email non valide. Restituisce un 400 oppure un 202 con un evento di bounce successivo?

Riepilogo dei compromessi

Aspetto | Coperto dalla compatibilità? | Azione necessaria

Payload della richiesta | Sì | Nessuna (se la specifica corrisponde)

Formato della risposta | Sì | Nessuna (se la specifica corrisponde)

Autenticazione del dominio | No | Aggiorna i record DNS

Reputazione degli IP | No | Periodo di warm-up

Prezzi/quote | No | Consulta le pagine dei prezzi dei fornitori

Eventi webhook | No | Aggiorna i listener degli eventi

La compatibilità è uno strumento di agilità, non una bacchetta magica per la deliverability. Separando l'interfaccia dall'infrastruttura, puoi ottimizzare costi e prestazioni senza vincolarti all'ecosistema di un solo fornitore.

Per un'API email pronta per gli agenti, con raccolta dati ridotta al minimo, che semplifica questa infrastruttura, scopri SendHQ.