Migrer depuis Resend

Limites de compatibilité

SendHQ accepte les champs JSON courants de style Resend pour les envois HTTP directs, mais ne remplace pas tel quel le SDK Resend. Pointez votre propre adaptateur HTTP côté serveur vers /api/v1/emails ; ne partez pas du principe qu’un SDK dont l’hôte Resend est codé en dur peut être reconfiguré.

Correspondance des champs

from, to, cc, bcc, subject, html, text, reply_to et les headers personnalisés sûrs se transposent directement. SendHQ accepte aussi message_class, les références de template hébergés, draft_id et les champs de réponse/fil. Les payloads React propres à Resend, les tableaux de pièces jointes inline, les tags, les audiences, les broadcasts et les champs d’envoi programmé n’ont pas d’équivalent accepté.

Pièces jointes et modèles

Téléversez les pièces jointes dans un brouillon SendHQ, puis envoyez avec draft_id. Les modèles hébergés sont des ressources SendHQ avec des versions publiées et des données typées ; migrez explicitement les identifiants de modèles et les appels de rendu plutôt que de copier l’identifiant de modèle d’un fournisseur.

Nouvelles tentatives

Générez une Idempotency-Key stable par envoi logique. Réessayez avec le même payload JSON et cette clé. Si l’objet, le corps, un destinataire, un en-tête ou les données du modèle changent, utilisez une nouvelle clé ; sinon SendHQ renvoie 409. Une réponse stockée rejouée inclut Idempotent-Replayed: true.

Checklist de bascule

1. Vérifiez chaque domaine From et chaque adresse d’expéditeur exacte que vous utiliserez.
2. Envoyez des messages texte et HTML contrôlés vers une boîte de réception qui vous appartient.
3. Vérifiez l’acceptation par le fournisseur indépendamment des événements de livraison.
4. Testez la gestion des codes 409, 422, 423, 429 et 5xx.
5. Gardez l’adaptateur du fournisseur précédent disponible jusqu’à ce que les parcours transactionnels et de cycle de vie soient validés.