> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/connectors/fr/custom-connector/emailsender-extensibility.md).

# Extensibilité d’EmailSender

Implémentez un fournisseur d’e-mails basé sur un script en enregistrant \`runtime.scriptable.emailEngine.SendEmail\`.

### Ce que c’est

Utilisez ce point d’extensibilité pour faire en sorte que l’équipe Wallet envoie des e-mails via un fournisseur sous le contrôle du locataire. Il s’agit d’une intégration au niveau du script. Elle conserve les modèles et la logique de rendu de l’équipe Wallet, tout en déléguant l’envoi final à des appels API dédiés.

Cette conception sépare le rendu de la livraison. Cela rend la couche e-mail plus facile à tester et à remplacer. Cela rend aussi la gestion des cultures explicite, car l’appelant décide quelles cultures existent et comment les modèles sont résolus.

### Comment `SendEmail` fonctionne

La plateforme appelle `runtime.scriptable.emailEngine.SendEmail` lorsqu’elle doit envoyer un e-mail et que le fournisseur d’e-mails est défini sur `script`. La fonction reçoit l’adresse du destinataire, le nom du modèle, une charge utile de données et la liste des cultures prises en charge.

Le dernier paramètre, `buildEmail`, est un rappel fourni par la plateforme. L’implémentation du fournisseur l’appelle pour obtenir le contenu final rendu. Ce rappel renvoie un objet avec un `Objet` et une `Body`. Une fois cette charge utile disponible, le script est responsable de son envoi.

### Implémentation de référence (signature)

```js
/**
 * @typedef {Object} EmailData
 * @property {string} Subject - Ligne d'objet rendue.
 * @property {string} Body - Contenu du corps rendu.
 */

/**
 * Envoyez un e-mail en utilisant le nom du modèle fourni et les données.
 * L'appelant fournit les cultures prises en charge et un rappel
 * pour générer le contenu de l'e-mail rendu.
 *
 * @param {string} recipient - Adresse e-mail cible.
 * @param {string} emailTemplate - Nom du modèle à rendre.
 * @param {Object.<string, any>} data - Données du modèle transmises au script.
 * @param {string[]} cultures - Noms de cultures disponibles fournis par le fournisseur de cultures.
 * @param {(templateName: string) => Promise<EmailData>} buildEmail
 * Fonction de rappel qui renvoie le contenu final de l'e-mail rendu.
 *
 * @returns {Promise<void>}
 */
async function sendEmail(recipient, emailTemplate, data, cultures, buildEmail){
   // appeler n’importe quelle API pour envoyer l’e-mail
}

export default function(context) {
  context.register('runtime.scriptable.emailEngine', {
    SendEmail : sendEmail 
  })
}
```

### Activer le fournisseur d’e-mails par script

Passer au fournisseur d’e-mails par script est un changement de configuration. Cela indique à l’équipe Wallet d’appeler l’implémentation du locataire `SendEmail` pour les e-mails sortants.

{% stepper %}
{% step %}

#### Modifiez `/server/emails.yml`

Ouvrez l’éditeur de configuration avancée, puis créez ou modifiez `/server/emails.yml`. Définissez le type de fournisseur sur `script`. Conservez `ressources` pointant vers le répertoire des modèles d’e-mails.
{% endstep %}
{% endstepper %}

```yaml
provider :
  type : script
resources :
  - /locales/emails/

```

### Notes sur les modèles et les cultures

Les modèles d’e-mails sont chargés à partir des chemins répertoriés sous `ressources`. Veillez à ce que cela corresponde à l’emplacement des modèles HTML, car le rappel de rendu utilise ces modèles.

La gestion des cultures fait partie du contrat. La plateforme transmet un `cultures` tableau, mais l’implémentation du fournisseur décide comment l’utiliser. En pratique, la plupart des configurations choisissent soit une culture unique par destinataire, soit reviennent à une culture par défaut lorsqu’aucun modèle spécifique n’existe.

### Dépannage

Si les e-mails cessent d’être envoyés après l’activation du fournisseur par script, commencez par vérifier que `/server/emails.yml` est un YAML valide et enregistré dans le bon locataire. Puis confirmez que le script est bien enregistré sous `runtime.scriptable.emailEngine` et exporte `SendEmail`.

Pour les erreurs côté fournisseur, consignez le nom du modèle et les choix de culture, mais évitez de consigner les corps rendus complets. Le contenu des e-mails peut contenir des données personnelles.

### FAQ

<details>

<summary><strong>Est-ce un point de terminaison HTTP public ?</strong></summary>

Non. Cette page documente une interface d’exécution de script que le script du locataire implémente. Une API HTTP externe est appelée depuis l’intérieur de `SendEmail`.

</details>

<details>

<summary><strong>Où se trouvent les modèles d’e-mails ?</strong></summary>

Ils se trouvent dans les répertoires listés dans `ressources`. Par défaut, cela pointe vers `/locales/emails/`.

</details>

<details>

<summary><strong>Un fournisseur par script peut-il être combiné avec SendGrid ou Mailchimp ?</strong></summary>

Pas en même temps pour un locataire donné. Le fournisseur actif est sélectionné dans `/server/emails.yml`.

</details>

<details>

<summary><strong>Que doit <code>SendEmail</code> renvoyer ?</strong></summary>

Retournez normalement lorsque l’e-mail est accepté par le fournisseur. Lancez une erreur lorsque l’envoi échoue, afin que la plateforme puisse l’afficher.

</details>

<details>

<summary><strong>Quel est le moyen le plus rapide de valider la configuration ?</strong></summary>

Activez le `script` fournisseur, déclenchez un seul e-mail transactionnel, puis vérifiez les journaux du fournisseur pour l’événement d’envoi.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.thewalletcrew.io/connectors/fr/custom-connector/emailsender-extensibility.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.