Journal des modifications

Les changements qui concernent l’API publique ou les SDK sont listés ici. Les paquets SDK suivent le versionnage sémantique ; leurs journaux de modifications détaillés sont publiés avec chaque version npm.

Non publié – bêta publique

SendGrid n’est plus pris en charge (octobre 2026)

Depuis le 1er octobre 2026, SendGrid n’est plus disponible comme fournisseur d’e-mails. Si vous envoyiez via un service SendGrid, passez à un autre fournisseur API comme Resend, Postmark, Mailgun, Brevo ou Mailjet, puis sélectionnez le nouveau service dans vos modèles (ainsi que comme service de secours si vous l’y utilisiez).

Traductions des modèles (septembre 2026)

Un même modèle peut désormais être envoyé dans plusieurs langues – voir Traductions des modèles.

• Tableau de bord : une barre Langues dans l’éditeur de modèles. Ajoutez jusqu’à 29 variantes linguistiques par modèle (n’importe quelle langue BCP 47, p. ex. hu ou pt-BR) – sous forme de copie de la langue par défaut, vides ou par traduction automatique. Les variantes traduisent l’objet, le HTML, le texte et le nom de l’expéditeur ; les destinataires, les paramètres et les réglages restent communs. Chaque variante a ses propres versions et sa restauration, ainsi que les badges Obsolète / Automatique. La langue par défaut du modèle peut être n’importe quelle langue (Paramètres → Général → Langue par défaut). L’export/import inclut les variantes.
• Traduction automatique avec votre propre clé : OpenAI, Anthropic, Google Gemini ou DeepL avec la clé API de votre organisation (Paramètres → Traduction automatique, propriétaires et administrateurs). Frontmail vérifie que les paramètres, les liens et la structure HTML sont intacts (translation_invalid). 30 traductions par heure et par organisation, jusqu’à 60 000 caractères. Nouveaux codes d’erreur translation_not_configured, translation_invalid, translation_provider_auth, translation_provider_error.
• API : locale facultatif dans POST /v1/send et dans les éléments de /v1/send-batch, champ de formulaire fm_locale dans POST /v1/send-form (un champ nommé locale reste un paramètre du modèle). Résolution : langue exacte → même langue de base (de-AT → de) → langue par défaut ; une balise mal formée donne 400 invalid_body. Les réponses d’envoi et les résultats des envois groupés renvoient la locale utilisée ; GET /v1/templates renvoie locales. Les réponses automatiques suivent la langue du message d’origine, Renvoyer la conserve. Les routes compatibles EmailJS utilisent toujours la langue par défaut.
• Mise en forme : les dates, les nombres, les montants et le pied de page du forfait Free suivent désormais la langue dans laquelle l’e-mail est envoyé (auparavant la langue de l’organisation).
• SDK JavaScript (prochaine version, 0.2.0 – avec le renforcement de la sécurité des SDK ci-dessous) : option locale dans send / sendForm (envoyée sous la forme fm_locale par sendForm), prop locale sur <FrontmailForm> (React, Vue, Svelte) et use:frontmailForm, result.locale ; @frontmail/node : locale sur send et sur les éléments de sendBatch, templates.list() renvoie locales, et frontmail types émet les langues de chaque modèle ainsi qu’un type <TemplateName>Locale. @frontmail/emailjs-compat est inchangé (langue par défaut uniquement).
• SDK Android / Kotlin 0.2.0 : SendOptions(locale = "de"), SendResult.locale.
• SDK iOS / Swift 0.2.0 : SendOptions(locale: "de"), SendResult.locale.

Renforcement de la sécurité : périphérie de l’API publique et clés (septembre 2026)

Changements de comportement – vérifiez votre intégration :

• Les requêtes sans Origin ni Referer (serveurs, curl, applications natives) avec la clé publique nécessitent désormais Autoriser les applications mobiles – y compris quand votre liste de sites autorisés est vide. Auparavant, une liste vide les acceptait. Les organisations qui ont envoyé de telles requêtes au cours des 30 derniers jours ont eu l’interrupteur activé automatiquement. Sinon : 403 origin_not_allowed (details.reason: "no_origin"). Sur les serveurs, utilisez une clé privée.
• Les clés privées provenant de navigateurs sont refusées : une requête par clé privée (Authorization: Bearer ou le champ accessToken à la manière d’EmailJS) qui porte un en-tête Origin reçoit la nouvelle erreur 403 private_key_in_browser. Activation possible pour les outils internes : Sécurité → Autoriser les clés privées dans les navigateurs.
• Le CAPTCHA des requêtes sans Origin n’est vérifié avec le widget mobile partagé de Frontmail que si Autoriser les applications mobiles est activé. Les clés de test Cloudflare sont refusées en production.
• Interrogation du statut : envoyez le jeton de statut dans l’en-tête X-Frontmail-Status-Token ; ?token= continue de fonctionner pour les anciens SDK.
• Rate limits : les clients IPv6 partagent la limite par IP par réseau /64. Les limites par clé et par organisation ainsi que la détection d’anomalies ne comptent plus que les requêtes qui ont passé les contrôles du modèle et du CAPTCHA : un afflux de requêtes invalides ne bloque plus vos vrais visiteurs.
• Pièces jointes : les noms de fichiers sont nettoyés (caractères invisibles/bidi, points finaux) et davantage de types dangereux sont refusés (HTML, SVG, images disque, OneNote, Office avec macros, .url, .lnk…). Les téléversements par clé publique (POST /v1/uploads) nécessitent un modèle qui accepte les pièces jointes et disposent d’un budget quotidien en octets par organisation.
• template_id / service_id multipart de plus de 64 caractères → 400 invalid_body (auparavant 500).
• L’API, l’API du tableau de bord et la connexion n’acceptent que le trafic qui passe par le CDN de Frontmail.

API

• POST /v1/send, /v1/send-form, /v1/send-batch, /v1/uploads, GET /v1/messages/:id, GET /v1/history, GET /v1/templates et alias compatibles EmailJS.
• Format d’erreur unifié avec docs_url ; prise en charge d’Idempotency-Key (24 h).
• File d’attente des e-mails retenus avec les statuts held / held_service_error et les modes hold / reject.
• Verrouillage du contenu pour les envois par clé publique vers des modèles à destinataire dynamique : CAPTCHA obligatoire (dynamic_recipient_requires_captcha), champs d’expéditeur fixes (dynamic_field_not_allowed), pas de paramètres HTML et textes ≤ 500 caractères, liens uniquement vers des domaines autorisés (link_not_allowed) et au maximum 5 e-mails par destinataire et par jour. Une adresse d’expéditeur issue des paramètres est refusée pour tout envoi par clé publique. Les réponses automatiques sont également verrouillées. Nouveaux réglages : security.allowedLinkDomains, security.recipientDailyLimit, enforceLinkAllowlist sur le modèle. Voir Liste des domaines de liens et verrouillage du contenu.

SDK

• @frontmail/browser 0.x (ESM + UMD, épinglez la version avec SRI), @frontmail/react, @frontmail/react-native, @frontmail/vue, @frontmail/svelte, @frontmail/node avec la CLI frontmail types, @frontmail/emailjs-compat.
• Nouvelles tentatives automatiques avec backoff exponentiel et clés d’idempotence ; erreurs typées.

Sécurité

• La validation en deux étapes s’applique désormais à toutes les méthodes de connexion – liens de connexion par e-mail et Google / GitHub compris – et ne peut être activée qu’avec une adresse e-mail vérifiée.
• Les liens de connexion et de vérification ouverts dans un autre navigateur demandent une confirmation (ou ne connectent pas ce navigateur) : un lien envoyé par quelqu’un d’autre ne peut pas vous connecter à son compte.
• Changer l’adresse e-mail de connexion nécessite votre mot de passe et l’approbation de l’adresse actuelle.
• Les administrateurs ne peuvent plus attribuer le rôle Facturation ; seul le propriétaire gère les administrateurs et les membres Facturation.
• Les URL de webhook des fournisseurs sont masquées pour les lecteurs et les membres Facturation et peuvent être régénérées (Générer une nouvelle URL de webhook).
• Les serveurs SMTP personnalisés doivent utiliser une adresse publique et le port 25, 465, 587 ou 2525.
• Les pièces jointes des modèles ne peuvent utiliser que des fichiers téléversés par la même organisation.
• Les invitations dans l’équipe sont limitées par destinataire et par organisation ; les noms d’organisation ne peuvent pas contenir de liens.
• Les données de suivi des clics exportées vers l’analytique ne contiennent plus de chaînes de requête (jetons, e-mails).

Renforcement de la sécurité des SDK (prochaine version des SDK, 0.2.0)

• Changement incompatible : les SDK navigateur (@frontmail/browser, React, Vue, Svelte, @frontmail/emailjs-compat) lèvent private_key_in_browser quand une clé privée (privateKey, accessToken pour compat) est utilisée dans un navigateur web ; @frontmail/node refuse de s’y exécuter. Désactivation : dangerouslyAllowPrivateKeyInBrowser: true.
• sendForm ignore les champs de mot de passe, les champs anti-CSRF et les noms réservés ; nouvelle option formFields: { include, exclude }.
• getStatus envoie le jeton de statut dans l’en-tête X-Frontmail-Status-Token au lieu de ?token=.
• Le <TurnstileWebView> de React Native est verrouillé sur la page du widget (origines, navigation, messages).
• CDN : sri.json avec les empreintes integrity à côté de chaque bundle versionné ; la documentation utilise des URL à version épinglée avec Subresource Integrity.

Tableau de bord

• Éditeur de modèles HTML avec aperçu en direct, paramètres typés, vérifications, versions et galerie (EN/CS).
• Services pour SMTP, Mailgun, Amazon SES, Postmark, SendGrid, Mailjet, Brevo, Resend, Gmail et Outlook / Microsoft 365, avec bascule vers un service de secours et vérifications d’état.
• Crédits : forfaits, packs de crédits, découvert, recharge automatique ; statistiques d’utilisation.

Facturation et crédits (correctifs de sécurité)

• Les forfaits annuels reçoivent désormais leur quota mensuel et leur marge de découvert chaque mois de la période (auparavant uniquement le premier mois).
• Le découvert utilisé sur les forfaits annuels est facturé mensuellement sur une facture séparée ; le découvert utilisé avant la fin d’un abonnement (résiliation, suppression de l’organisation) est facturé immédiatement.
• Le passage du mensuel à l’annuel reporte les crédits utilisés dans le mois en cours.
• Les changements de forfait sont refusés tant que l’abonnement a une facture impayée (409 conflict, details.reason: "subscription_not_active").
• Les paiements contestés (rétrofacturés) retirent les crédits qu’ils avaient achetés ; ceux-ci sont restitués si la contestation est gagnée. Les remboursements sont traités remboursement par remboursement.
• Nouveau : la file d’attente des e-mails retenus est limitée par organisation ; au-delà de la limite, les requêtes reçoivent 402 insufficient_credits avec details.reason: "hold_queue_full".
• Nouveau : les e-mails envoyés avec la clé publique n’utilisent pas le découvert et ne déclenchent pas la recharge automatique, sauf activation dans Facturation → Acheter des crédits → Dépenses liées au trafic par clé publique (désactivé par défaut, y compris pour les organisations existantes).
• Serveurs SMTP personnalisés : les échecs survenant après la réception du message par le serveur ne sont plus remboursés ; un garde-fou sur le taux de remboursement par organisation stoppe les remboursements quand les échecs sont anormalement fréquents.
• Les webhooks des fournisseurs ne bloquent que les destinataires réels du message ; les webhooks Amazon SES épinglent la rubrique SNS du premier message signé. Renvoyer refuse les modèles gelés suite à un passage à un forfait inférieur.