# Venir de Resend L’API de Mail reprend le format de Resend. Une requête écrite pour Resend part presque telle quelle : il faut changer l’adresse de l’API, la clé et le domaine d’envoi. Cette page dit ce qui ne bouge pas, ce qui change et ce qu’il reste à faire. ## Ce qui ne change pas - **Le format des requêtes** : `from`, `to`, `subject`, `html`, `text`, `cc`, `bcc`, `reply_to`, `headers` et `tags` ont le même nom et le même sens. - **Le chemin des envois** : `POST /emails` pour un e-mail, `POST /emails/batch` pour un lot de 100 au plus. - **La réponse** : un envoi réussi renvoie `{ "id": "…" }`, et un lot renvoie `{ "data": [{ "id": "…" }, …] }`. - **Les erreurs** : même forme, avec `statusCode`, `name` et `message`. Le détail des codes est dans [Erreurs](/docs/reference/erreurs/). - **L’authentification** : un en-tête `Authorization: Bearer …`. - **L’idempotence** : l’en-tête `Idempotency-Key` fonctionne de la même façon. Voir [Envoyer sans doublon](/docs/guides/envoyer-sans-doublon/). ## Ce qui change | Élément | Resend | Mail | | --------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | Adresse de base | `https://api.resend.com` | L’adresse de l’API de ton espace, voir [Introduction à l’API](/docs/reference/api/) | | Préfixe de clé | `re_…` | `am_…` | | Domaine d’envoi | Vérifié chez Resend | À vérifier dans ton espace Mail, avec tes propres enregistrements DNS | | Pied de page | Rien, sauf ce que tu ajoutes | Chaque e-mail envoyé par l’API porte la mention « Propulsé par HGDC ». Elle est ajoutée à l’envoi et ne se retire pas. | | Désabonnement | Ce que tu ajoutes | Un e-mail envoyé à un seul destinataire peut recevoir `{{lien_desabonnement}}`, rempli à l’envoi. Les campagnes et les workflows ont toujours le lien. | > **Attention** > > Le domaine ne se transfère pas : un domaine vérifié chez Resend doit être vérifié à nouveau dans Mail, avec ses propres enregistrements DNS. Prépare-le avant de couper Resend. ## Les variables Les formes courantes des modèles Resend marchent sans retouche. `{{{FIRST_NAME}}}` et `{{{LAST_NAME}}}` sont acceptés tels quels. | Forme Resend | Chez Mail | | ------------------------------ | -------------------------------------------------------------------- | | `{{{FIRST_NAME}}}` | `{{{FIRST_NAME}}}` (accepté) ou `{{prenom}}` | | `{{{LAST_NAME}}}` | `{{{LAST_NAME}}}` (accepté) ou `{{nom}}` | | `{{{RESEND_UNSUBSCRIBE_URL}}}` | `{{{RESEND_UNSUBSCRIBE_URL}}}` (accepté) ou `{{lien_desabonnement}}` | Pour la liste complète et les valeurs de secours (`{{prenom|à toi}}`), voir [Variables](/docs/reference/variables/) et [API e-mails](/docs/reference/api-emails/). ## Garder le SDK Resend Si ton code utilise le SDK Resend officiel, tu peux le garder en changeant seulement l’adresse de base et la clé. La façon de les régler dépend de ta version du SDK : vérifie qu’elle accepte une adresse de base personnalisée, sinon passe-la explicitement à la création du client. Le client TypeScript de Mail, dans [Premier envoi depuis Node.js](/docs/demarrer/premier-envoi-node/), renvoie des erreurs typées : c’est souvent le chemin le plus simple. ## Ce qui n’est pas encore pris en charge Ces champs de Resend ne sont pas gérés. L’API les **refuse** avec un `422` au lieu de les ignorer : une pièce jointe ou un envoi programmé ne disparaît pas en silence. | Champ | Ce qui se passe | Que faire | | -------------- | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | `attachments` | Refusé (`422`) | Héberge le fichier et mets un lien dans le message. | | `scheduled_at` | Refusé (`422`) | Envoie au moment voulu depuis ton système, ou prépare un workflow avec une attente. | | `react` | Refusé (`422`) | Envoie le HTML rendu, dans `html`. | | `topic_id` | Refusé (`422`) | Retire le champ. Le désabonnement passe par le lien de l’e-mail, voir [Désabonnement et blocages](/docs/concepts/desabonnement-et-blocages/). | ## Checklist de bascule 1. Le domaine d’envoi est **Prêt** dans **Domaines**. 2. Une clé `am_…` est créée dans **Clés d’API**, et rangée dans tes variables d’environnement. 3. L’adresse de base pointe sur l’API de Mail, et l’ancienne clé `re_…` n’est plus lue nulle part. 4. Aucun appel n’utilise `attachments`, `scheduled_at`, `react` ou `topic_id`. 5. Les variables des modèles sont vérifiées, avec une valeur de secours là où un contact peut ne pas avoir l’information. 6. Un envoi test part vers une adresse à toi, et apparaît dans **E-mails**. 7. Les envois qui doivent être uniques passent par `Idempotency-Key`, avec une clé métier. 8. Si ton code lit le statut d’un e-mail, vérifie les valeurs reçues. Elles sont décrites dans [Statuts des e-mails](/docs/reference/statuts-des-e-mails/). 9. Tu envoies un petit volume pendant quelques jours, puis tu montes. Un domaine neuf a besoin de temps pour gagner sa réputation. Voir [Délivrabilité](/docs/concepts/delivrabilite/). 10. Ta clé Resend est révoquée une fois la bascule confirmée. ## Si ça ne marche pas - **`422` sur un champ** : le champ est dans la liste des champs non pris en charge. Retire-le ou remplace-le par son équivalent. - **`403 invalid_api_key` après la bascule** : l’ancienne clé `re_…` est encore utilisée quelque part. Remplace-la par une clé `am_…`.