Intégration API Resend
Nous développons votre connecteur Resend
Nous branchons Resend à votre produit : confirmation, reset, facture PDF. Chaque envoi est rattaché à une intention métier, sans double envoi ni campagne marketing forcée.
- Équipe produit senior
- connecteurs email en production
- du cadrage au monitoring
À quoi sert l'API Resend et quand choisir Resend pour ses emails applicatifs ?
Resend est un service d'envoi d'emails transactionnels conçu pour les développeurs, avec une API simple, des logs en temps réel et une gestion native des domaines d'envoi. On le choisit pour les emails déclenchés par votre application : confirmation d'inscription, lien de connexion, notification d'événement, quand la priorité est la délivrabilité et la traçabilité, pas les campagnes marketing. L'idempotence de l'API garantit qu'un email comme un magic link ne part pas deux fois, même en cas de retry. La plateforme supporte l'envoi depuis une région européenne pour les projets avec des contraintes de localisation des données.
Ce que nos clients construisent sur l'API Resend
Magic links et reset de mot de passe
Lien de connexion ou reset : un même envoi ne part pas deux fois si la file rejoue. Le client reçoit un seul lien utilisable.
Factures PDF en pièce jointe
La facture part en pièce jointe. Si la livraison échoue, le dossier est marqué « e-mail non rendu », sans surveillance manuelle.
Onboarding sans double bienvenue
Bienvenue et relance J+3 partent groupés, sans envoyer deux fois le même message au même compte.
Alertes produit avec latence européenne
L'envoi part d'Irlande pour un meilleur délai en Europe. On dit franchement où vivent les logs : ce n'est pas un compte UE.
Ce que ça change dans vos emails transactionnels
La technique au service d'un résultat mesurable : zéro double magic link, un statut de livraison fiable, une résidence dite franchement.
Un rejeu n'envoie plus un second e-mail
Chaque intention (reset, facture, bienvenue) a une clé métier. Si la file rejoue, le client ne reçoit pas deux liens.
Vous savez si l'e-mail est arrivé
Les notifications de livraison sont vérifiées. Vous ouvrez un accès ou fermez un compte sur un statut fiable, pas sur un espoir.
La région d'envoi n'est pas la résidence
Choisir l'Europe pour le délai d'inbox ne déplace pas automatiquement les logs. On l'écrit clairement dans le cadrage.
Le marketing reste dans l'outil marketing
Resend couvre le transactionnel. Campagnes, listes et SMS restent chez Mailjet ou Brevo : pas de mauvais usage forcé.
Comment nous livrons votre connecteur Resend
Cadrage
Quels emails, quel volume, DPA US acceptable ou non. On écrit la décision de résidence, la région d'envoi, et ce qui reste dans l'ESP.
Développement
Idempotency-Key dérivée de l'intention, file unique par équipe, Svix sur corps brut, respect de ratelimit-* et retry-after.
Recette
Domaine resend.dev, jamais le domaine de prod. 409 sur payload divergent, replay hors 24 h, webhook hors fenêtre rejeté.
Monitoring
Alertes 429 et quota, journal des clés d'idempotence, file morte inspectable. Vous voyez un seau d'équipe saturé avant vos utilisateurs.
Ce que permet l'API Resend
- Envoi unitaire idempotent
- POST /emails avec Idempotency-Key (1 à 256 caractères), mémorisée 24 heures. Même clé + même payload = même réponse, pas de second envoi.
- Batch jusqu'à 100
- POST /emails/batch, une clé d'idempotence pour le lot, pas pour chaque ligne. SMTP : Resend-Idempotency-Key.
- Webhooks Svix
- En-têtes svix-id, svix-timestamp, svix-signature. Vérifier le corps brut avec le signing secret. Le secret n'est montré qu'à la création ou à la lecture.
- Régions d'envoi, résidence US
- us-east-1, eu-west-1, sa-east-1, ap-northeast-1. eu-west-1 améliore le time-to-inbox européen. Ça ne déplace pas les logs.
Le vocabulaire de l'API Resend
- Idempotency-Key
- En-tête 1 à 256 caractères, mémorisé 24 heures. Dérivé de l'intention, jamais un UUID régénéré dans le retry de la file. Au-delà de 24 h, la même clé n'existe plus.
- 409 invalid_idempotent_request
- Même clé, autre payload. Réutiliser welcome-user/123 pour un e-mail différent (changement de gabarit) est une erreur. La clé identifie le payload, pas l'utilisateur.
- svix-signature
- HMAC Svix sur le corps brut, avec svix-id et svix-timestamp. Parser le JSON puis re-signer échoue. Dédup sur svix-id, rejet hors fenêtre de timestamp.
- eu-west-1
- Région d'envoi Irlande. « It does not control where customer data is stored. » Une page « Resend Europe » qui laisse croire que les logs sont en Irlande est fausse.
- ratelimit-*
- En-têtes IETF : limit, remaining, reset, plus retry-after. Un cron de relance et le trafic web partagent le seau. File unique par équipe.
- 10 rps / équipe
- Défaut documenté, toutes les clés du compte. 429 daily_quota_exceeded ou monthly_quota_exceeded sur les offres à quota e-mails.
Les contraintes réelles de l'API Resend
La résidence est aux États-Unis
Toutes les données de compte restent aux États-Unis. eu-west-1 = dispatch depuis l'Irlande. Si le client exige un stockage UE, Mailjet ou Brevo se discutent, pas un slogan « Resend Europe ».
La fenêtre d'idempotence dure 24 h
Au-delà, un replay tardif renvoie. Votre table d'envois doit vivre plus longtemps que Resend. 409 concurrent_idempotent_requests existe aussi.
10 requêtes par seconde par équipe
Toutes clés confondues. Deux workers indépendants vident le seau. On pose une file unique, on lit retry-after, on ne lance pas un cron parallèle au trafic web.
Ce n'est pas un ESP
Pas de listes, segments, SMS v4, parse inbound au même titre. Forcer un usage marketing de masse dans Resend est un mauvais cadrage (quotas contacts, produit).
Resend ou Mailjet pour vos emails ?
Une API d'envoi idempotente d'un côté, un ESP de l'autre. Choisir l'un ou l'autre est une décision de résidence et de produit, pas un choix de SDK.
| Critère | ResendCette page | MailjetESP |
|---|---|---|
| Produit | API d'envoi, broadcasts limités | ESP : tx, marketing, contacts, SMS |
| Idempotence | Idempotency-Key, fenêtre 24 h | CustomID (corrélation, pas anti-doublon) |
| Webhooks | Svix, HMAC, en-têtes svix-* | eventcallbackurl v2, pas de HMAC dans le guide |
| Sandbox | Domaine resend.dev / clés de test | SandboxMode racine |
| Résidence | Compte US, envoi optionnel eu-west-1 | DPA du compte à relire |
| Débit documenté | 10 req/s par équipe, en-têtes IETF | 429, chiffres non publiés |
| Le bon cas | Email transactionnel idempotent de SaaS | Tx + marketing + SMS dans un compte |
Les deux se combinent : Resend pour le magic link, Mailjet pour le cycle de vie et les listes. C'est un arbitrage de cadrage, pas un choix définitif.
Ce que nous mesurons sur une intégration Resend
Les autres API d'envoi
Si l'idempotence native n'est pas le critère, ces options se discutent au cadrage.
ResendNous développons votre connecteur ResendCette page
TwilioOpérateur programmable : SMS, WhatsApp, voix et OTP prêt à l'emploi.
BrevoEmail transactionnel et SMS dans un compte français, gabarits inclus.
RingoverTéléphonie française : appels, remontée de fiche et SMS métier.
MailjetNous développons votre connecteur MailjetOn combine Resend avec
La stack qui entoure Resend sur nos projets.
Intégration Resend : vos questions
Trois étapes. Une clé re_ par environnement, en coffre, jamais partagée entre la CI et la production. Un connecteur POST /emails dont l'Idempotency-Key est dérivée de l'intention (reset/userId/tokenId), pas d'un UUID régénéré au retry, plus une table d'envois qui vit plus de 24 h. Une file unique par équipe Resend, qui lit ratelimit-* et retry-after : le défaut est 10 requêtes par seconde, toutes clés confondues. Puis les webhooks Svix : corps brut, signing secret, rejet hors fenêtre de timestamp, dédup svix-id. La partie sensible n'est pas le SDK : c'est la résidence US, à écrire avant de promettre l'Europe.
Un premier flux utile, typiquement magic link ou facture avec idempotence et webhook d'échec, se livre en deux à trois semaines. Une chaîne complète avec batch, domaines multi-région, rotation DNS et frontière nette vis-à-vis de l'ESP marketing demande plutôt quatre à six semaines. Le DNS et le DPA pèsent souvent plus que POST /emails. Nous cadrons le périmètre en amont et donnons une estimation ferme avant de commencer.
Non. eu-west-1 est une région d'envoi (Irlande). La documentation est explicite : ça ne contrôle pas où les données client sont stockées. Métadonnées, logs et enregistrements API restent aux États-Unis. Le RGPD passe par le DPA et les CCT, pas par le hostname d'envoi. Si le questionnaire exige un stockage UE, on discute Mailjet ou Brevo, on n'écrit pas « Resend Europe » sur une page. C'est le test de sérieux du cadrage.
Resend est une API d'envoi : Idempotency-Key 24 h, webhooks Svix signés, DX courte, pas un ESP. Mailjet est un ESP : CustomID, SandboxMode, listes, SMS v4, pas d'HMAC webhook dans le guide, pas d'Idempotency-Key. On choisit Resend quand un retry ne doit pas renvoyer le magic link, et que le stockage US est accepté. On choisit Mailjet quand le marketing et le produit partagent la liste. Les deux se combinent. Ce n'est pas un choix de SDK.
Parce que la clé identifie le payload, pas l'utilisateur. Réutiliser welcome-user/123 après un changement de gabarit est 409 invalid_idempotent_request. Un UUID neuf à chaque retry de file annule l'idempotence : Resend voit un autre envoi. 409 concurrent_idempotent_requests existe aussi si deux workers partent ensemble. Nous calculons la clé sur l'intention, nous sérialisons les retries, et nous gardons notre table plus de 24 h, parce qu'au-delà Resend a oublié la clé.
Un projet d'intégration Resend ?
Parlons-en. 30 minutes pour cadrer vos envois, vérifier résidence et idempotence, et vous dire franchement ce qui est faisable.
Parler de mon projet Resend