Lister les modèles
Tous les modèles de la connexion, du plus récent au plus ancien, paginés par keyset.
Exécute le véritable appel sur votre espace de travail, avec votre propre clé.
GET /templates
Tous les modèles de la connexion, du plus récent au plus ancien, paginés par keyset.
Deux moteurs
export OE=https://api.openemail.ukexport AUTH="Authorization: Bearer $OPENEMAIL_API_KEY"Un modèle est un corps stocké une fois et envoyé de nombreuses fois, et il appartient à la CONNEXION plutôt qu'à celui qui l'a écrit. Une clé d'espace de travail voit les mêmes modèles qu'un collègue, et supprimer le compte de l'auteur ne les emporte pas.
engine: "blocks" stocke un arbre dont les types de nœuds sont les exports de @react-email/components (Section, Row, Column, Container, Text, Heading, Button, Link, Img, Hr, Markdown, CodeBlock et CodeInline) et dont les props sont celles de ces composants. Il est validé à l'entrée : un nœud incorrect est donc un 422 sur l'appel qui l'a écrit plutôt qu'un e-mail cassé plus tard.
engine: "html" stocke le balisage que vous avez déjà, assaini une fois à la publication de la version. C'est celui à choisir quand vos modèles sont des composants react-email qui vivent dans votre propre dépôt : rendez le composant avec @react-email/render dans votre propre build et postez le résultat. Il n'y a pas d'endpoint JSX et il n'y en aura pas. L'API prend du HTML parce que le HTML est ce que lit un client de messagerie, et exécuter le composant d'un appelant nous vaudrait un bac à sable dont personne n'a besoin.
| Déclaré comme | Rempli par | Absent à l'envoi |
|---|---|---|
| `slots` | celui qui modifie le modèle | le default du slot lui-même est rendu |
| `props` | celui qui envoie | missing_template_prop, un 422, et aucun courrier ne part |
Tous deux s'écrivent {{key}} dans le corps et dans l'objet, et tous deux portent un kind (text, url ou image) qui décide comment la valeur est échappée lors de la substitution. Une clé que rien ne déclare échoue à la publication ; une valeur url dont le schéma n'est ni http, ni https, ni mailto est refusée plutôt que rendue.
Une version publiée est figée. Modifier le corps d'un modèle publié crée un nouveau brouillon au lieu de changer ce que résolvent les envois en cours : un collègue qui réécrit le texte ne peut donc pas changer ce que votre code envoie déjà, et figer version fait qu'il ne le changera pas non plus en publiant.
Exemple
Nécessite templates:read. limit monte à 100, status restreint à draft, active ou archived, et cursor est opaque : renvoyez le nextCursor qu'on vous a donné plutôt que d'en fabriquer un.
curl "$OE/templates?limit=25&status=active" -H "$AUTH"{ "object": "list", "data": [ { "object": "template", "id": "tpl_9c1f0a4b7e05d3862c1f0a44", "name": "Order shipped", "slug": "order-shipped", "description": null, "status": "active", "publishedVersion": 3, "latestVersion": 4, "createdAt": "2026-08-01T09:12:44.000Z", "updatedAt": "2026-08-28T16:03:10.000Z" } ], "hasMore": false, "nextCursor": null}publishedVersion est ce que résout un envoi sans version, et latestVersion est le brouillon posé par-dessus. Un écart entre les deux signifie que quelqu'un a modifié sans publier. Ce n'est pas une erreur, et cela mérite d'apparaître dans un journal de déploiement.
Une ligne, ce sont des métadonnées. Les slots et props déclarés reviennent d'une récupération, l'appel à faire quand vous devez savoir quoi passer à un modèle.