Temple : le moteur de templates d’Emailit, enfin documenté

Si vous avez déjà utilisé {{first_name}} dans un modèle Emailit, vous avez déjà utilisé Temple, notre petit moteur de templates pour les objets, le HTML et le texte. Nous n’en avions jamais publié de référence complète. C’est désormais chose faite dans la documentation : Temple.

Temple n’est ni Liquid ni Handlebars. Il fait bien quelques choses, et s’arrête là.

Ce que vous pouvez écrire

Des variables, y compris avec des chemins imbriqués :

Hello {{first_name}}
Item {{order.items.0.sku}}

Des valeurs par défaut quand une valeur manque :

Hi {{first_name|"there"}}

Des conditions (sans comparaison, uniquement vrai ou faux) :

{{#if plan}}
You are on the {{plan}} plan.
{{else}}
You are on the free plan.
{{/if}}

Pas de boucles, pas de helpers personnalisés, pas de partials. Les variables manquantes deviennent des chaînes vides.

Où il s’exécute vraiment

C’est la partie qui n’était pas documentée, et sur laquelle il est facile de se tromper.

• API POST /emails : Temple s’exécute quand vous passez un template et/ou un objet variables, y compris avec du HTML inline.
• Automatisation, étape Send Email : Temple s’exécute toujours. Les automatisations de contacts exposent {{email}}, {{first_name}} et {{custom_fields.*}} à la racine, ainsi que contact, payload et meta.
• Modèles dans le tableau de bord : les balises sont enregistrées telles quelles. Le rendu a lieu au moment de l’envoi.
• Campagnes : pas de Temple. Uniquement {{first_name}}, {{last_name}}, {{email}}, {{unsubscribe_url}} et {{cf.field}}.
• SMTP : aucun rendu côté serveur. Le MIME que vous soumettez est exactement ce que nous envoyons.

Les champs personnalisés des campagnes s’écrivent {{cf.plan}}. Ceux des automatisations s’écrivent {{custom_fields.plan}}. Mêmes données de contact, préfixes différents.

Pour commencer

Lisez la référence complète de Temple, avec le tableau de disponibilité et des exemples, ou envoyez un modèle via l’API e-mail avec un objet variables.