Novità

Qui sono elencate le modifiche che riguardano l’API pubblica o gli SDK. I pacchetti SDK seguono il versionamento semantico; i loro changelog dettagliati vengono pubblicati con ogni release su npm.

Non ancora rilasciato – beta pubblica

SendGrid non è più supportato (ottobre 2026)

Dal 1° ottobre 2026 SendGrid non è più disponibile come provider email. Se inviavi tramite un servizio SendGrid, passa a un altro provider API come Resend, Postmark, Mailgun, Brevo o Mailjet, poi seleziona il nuovo servizio nei tuoi modelli (anche come servizio di riserva, se lo usavi lì).

Traduzioni dei modelli (settembre 2026)

Un modello ora può essere inviato in più lingue – vedi Traduzioni dei modelli.

• Dashboard: una barra Lingue nell’editor dei modelli. Aggiungi fino a 29 varianti linguistiche per modello (qualsiasi lingua BCP 47, ad es. hu o pt-BR) – come copia della lingua predefinita, vuote o con la traduzione automatica. Le varianti traducono oggetto, HTML, testo e nome del mittente; destinatari, parametri e impostazioni restano comuni. Ogni variante ha le sue versioni e il suo rollback, oltre alle etichette Non aggiornata / Automatica. La lingua predefinita del modello può essere qualsiasi lingua (Impostazioni → Generale → Lingua predefinita). Export/import include le varianti.
• Traduzione automatica con la tua chiave: OpenAI, Anthropic, Google Gemini o DeepL con la chiave API della tua organizzazione (Impostazioni → Traduzione automatica, proprietari e admin). Frontmail verifica che parametri, link e struttura HTML siano rimasti intatti (translation_invalid). 30 traduzioni all’ora per organizzazione, fino a 60.000 caratteri. Nuovi codici di errore translation_not_configured, translation_invalid, translation_provider_auth, translation_provider_error.
• API: locale facoltativo in POST /v1/send e negli elementi di /v1/send-batch, campo del modulo fm_locale in POST /v1/send-form (un campo chiamato locale resta un parametro del modello). Risoluzione: lingua esatta → stessa lingua di base (de-AT → de) → lingua predefinita; un tag non valido dà 400 invalid_body. Le risposte di invio e i risultati dei batch restituiscono il locale usato; GET /v1/templates restituisce locales. Le risposte automatiche seguono la lingua del messaggio originale, Invia di nuovo la mantiene. Le route compatibili con EmailJS usano sempre la lingua predefinita.
• Formattazione: date, numeri, importi e il piè di pagina del piano Free ora seguono la lingua in cui viene inviata l’email (prima la lingua dell’organizzazione).
• SDK JavaScript (prossima release, 0.2.0 – insieme al rafforzamento della sicurezza degli SDK qui sotto): opzione locale in send / sendForm (inviata come fm_locale da sendForm), prop locale su <FrontmailForm> (React, Vue, Svelte) e use:frontmailForm, result.locale; @frontmail/node: locale su send e sugli elementi di sendBatch, templates.list() restituisce locales e frontmail types genera le lingue di ogni modello più un tipo <TemplateName>Locale. @frontmail/emailjs-compat non cambia (solo lingua predefinita).
• SDK Android / Kotlin 0.2.0: SendOptions(locale = "de"), SendResult.locale.
• SDK iOS / Swift 0.2.0: SendOptions(locale: "de"), SendResult.locale.

Rafforzamento della sicurezza: edge dell’API pubblica e chiavi (settembre 2026)

Cambiamenti di comportamento – controlla la tua integrazione:

• Le richieste senza Origin e Referer (server, curl, app native) con la chiave pubblica ora richiedono Consenti app mobile – anche quando l’elenco dei siti consentiti è vuoto. Prima un elenco vuoto le accettava. Per le organizzazioni che hanno inviato richieste di questo tipo negli ultimi 30 giorni l’interruttore è stato attivato automaticamente. Altrimenti: 403 origin_not_allowed (details.reason: "no_origin"). Sui server usa una chiave privata.
• Le chiavi private dai browser vengono rifiutate: una richiesta con chiave privata (Authorization: Bearer o il campo accessToken in stile EmailJS) che porta un header Origin riceve il nuovo errore 403 private_key_in_browser. Per gli strumenti interni si può attivare in Sicurezza → Consenti chiavi private nei browser.
• Il CAPTCHA per le richieste senza Origin viene verificato con il widget mobile condiviso di Frontmail solo quando Consenti app mobile è attivo. Le chiavi di test di Cloudflare vengono rifiutate in produzione.
• Polling dello stato: invia il token di stato nell’header X-Frontmail-Status-Token; ?token= continua a funzionare per gli SDK meno recenti.
• Rate limit: i client IPv6 condividono il limite per IP per ogni rete /64. I limiti per chiave e per organizzazione e il rilevamento delle anomalie ora contano solo le richieste che hanno superato i controlli del modello e del CAPTCHA, così una raffica di richieste non valide non blocca più i tuoi visitatori reali.
• Allegati: i nomi dei file vengono ripuliti (caratteri invisibili/bidi, punti finali) e vengono rifiutati altri tipi pericolosi (HTML, SVG, immagini disco, OneNote, file Office con macro, .url, .lnk, …). Gli upload con chiave pubblica (POST /v1/uploads) richiedono un modello che accetti allegati e hanno un budget giornaliero di byte per organizzazione.
• template_id / service_id multipart oltre i 64 caratteri → 400 invalid_body (prima 500).
• L’API, l’API della dashboard e l’accesso accettano solo traffico che passa dalla CDN di Frontmail.

API

• POST /v1/send, /v1/send-form, /v1/send-batch, /v1/uploads, GET /v1/messages/:id, GET /v1/history, GET /v1/templates e alias compatibili con EmailJS.
• Formato degli errori unificato con docs_url; supporto per Idempotency-Key (24 h).
• Coda dei messaggi in attesa con gli stati held / held_service_error e le modalità hold / reject.
• Blocco del contenuto per gli invii con chiave pubblica a modelli con destinatario dinamico: CAPTCHA obbligatorio (dynamic_recipient_requires_captcha), campi del mittente fissi (dynamic_field_not_allowed), nessun parametro HTML e testi ≤ 500 caratteri, link solo verso domini consentiti (link_not_allowed) e al massimo 5 email per destinatario al giorno. Un indirizzo From preso dai parametri viene rifiutato per ogni invio con chiave pubblica. Anche le risposte automatiche sono bloccate. Nuove impostazioni: security.allowedLinkDomains, security.recipientDailyLimit, enforceLinkAllowlist del modello. Vedi Allowlist dei link e blocco del contenuto.

SDK

• @frontmail/browser 0.x (ESM + UMD, fissa la versione con SRI), @frontmail/react, @frontmail/react-native, @frontmail/vue, @frontmail/svelte, @frontmail/node con la CLI frontmail types, @frontmail/emailjs-compat.
• Nuovi tentativi automatici con backoff esponenziale e chiavi di idempotenza; errori tipizzati.

Sicurezza

• La verifica in due passaggi ora è richiesta per ogni metodo di accesso – compresi i link di accesso via email e Google / GitHub – e si può attivare solo con un indirizzo email verificato.
• I link di accesso e di verifica aperti in un altro browser chiedono una conferma (o non fanno accedere quel browser), così un link inviato da qualcun altro non può farti accedere al suo account.
• Per cambiare l’email di accesso servono la password e l’approvazione dall’indirizzo attuale.
• Gli admin non possono più assegnare il ruolo Fatturazione; solo il proprietario gestisce admin e membri con ruolo di fatturazione.
• Gli URL dei webhook dei provider sono nascosti a osservatori e membri con ruolo di fatturazione e possono essere rigenerati (Genera nuovo URL del webhook).
• I server SMTP personalizzati devono usare un indirizzo pubblico e la porta 25, 465, 587 o 2525.
• Gli allegati dei modelli possono usare solo file caricati dalla stessa organizzazione.
• Gli inviti al team sono limitati per destinatario e organizzazione; i nomi delle organizzazioni non possono contenere link.
• I dati sul tracciamento dei clic esportati verso gli strumenti di analisi non contengono più query string (token, email).

Rafforzamento della sicurezza degli SDK (prossima release degli SDK, 0.2.0)

• Breaking: gli SDK per browser (@frontmail/browser, React, Vue, Svelte, @frontmail/emailjs-compat) lanciano private_key_in_browser quando in un browser web viene usata una chiave privata (privateKey, accessToken nel compat); @frontmail/node si rifiuta di funzionare lì. Per disattivarlo: dangerouslyAllowPrivateKeyInBrowser: true.
• sendForm salta i campi password, i campi anti-CSRF e i nomi riservati; nuovo formFields: { include, exclude }.
• getStatus invia il token di stato nell’header X-Frontmail-Status-Token invece che in ?token=.
• <TurnstileWebView> di React Native è vincolato alla pagina del widget (origini, navigazione, messaggi).
• CDN: sri.json con gli hash integrity accanto a ogni bundle versionato; la documentazione usa URL con versione fissata e Subresource Integrity.

Dashboard

• Editor di modelli HTML con anteprima in tempo reale, parametri tipizzati, controlli, versioni e galleria (EN/CS).
• Servizi per SMTP, Mailgun, Amazon SES, Postmark, SendGrid, Mailjet, Brevo, Resend, Gmail e Outlook / Microsoft 365, con failover e controlli di stato.
• Crediti: piani, pacchetti di crediti, scoperto, ricarica automatica; statistiche di utilizzo.

Fatturazione e crediti (correzioni di sicurezza)

• I piani annuali ora ricevono la quota mensile e il margine di scoperto in ogni mese del periodo (prima solo nel primo mese).
• Lo scoperto usato sui piani annuali viene addebitato mensilmente con una fattura separata; lo scoperto usato prima della fine di un abbonamento (annullamento, eliminazione dell’organizzazione) viene addebitato subito.
• Il passaggio da mensile ad annuale riporta i crediti usati nel mese corrente.
• I cambi di piano vengono rifiutati finché l’abbonamento ha una fattura non pagata (409 conflict, details.reason: "subscription_not_active").
• I pagamenti contestati (chargeback) rimuovono i crediti acquistati con essi; vengono ripristinati se la contestazione viene vinta. I rimborsi vengono elaborati singolarmente.
• Novità: la coda dei messaggi in attesa è limitata per organizzazione; oltre il limite le richieste ricevono 402 insufficient_credits con details.reason: "hold_queue_full".
• Novità: le email inviate con la chiave pubblica non usano lo scoperto e non attivano la ricarica automatica, a meno che non sia abilitato in Fatturazione → Acquista crediti → Spesa dal traffico con chiave pubblica (disattivato per impostazione predefinita, anche per le organizzazioni esistenti).
• Server SMTP personalizzati: gli errori successivi alla ricezione del messaggio da parte del server non vengono più rimborsati; una protezione sul tasso di rimborsi per organizzazione blocca i rimborsi quando gli errori sono anomalmente frequenti.
• I webhook dei provider aggiungono alla lista di soppressione solo i destinatari effettivi del messaggio; i webhook di Amazon SES fissano il topic SNS del primo messaggio firmato. Invia di nuovo rifiuta i modelli congelati dopo il passaggio a un piano inferiore.