Cosa significa "Invia per conto" nell'API di posta elettronica?
L'invio di e-mail per conto di un utente significa che la tua applicazione invia messaggi direttamente dalla casella di posta dell'utente, non da un mittente transazionale condiviso. Il destinatario vede l'indirizzo e-mail reale dell'utente nel campo "Da". Questa è la base di qualsiasi prodotto SaaS che gestisce e-mail per i propri utenti.
Cosa imparerai
Perché i prodotti SaaS necessitano dell'invio di email per conto terzi
La maggior parte dei prodotti SaaS che gestiscono l'email alla fine si trova ad affrontare la stessa esigenza: l'utente vuole che i messaggi provengano dal proprio indirizzo, non da un dominio generico della piattaforma. Che si tratti di un CRM, di un assistente di scrittura AI o di uno strumento di supporto, nel momento in cui il tuo prodotto invia email per conto degli utenti, hai bisogno dell'invio per conto terzi. Ecco perché è importante, e come i tre principali casi d'uso si allineano all'API.
I venditori inviano dalla loro reale Gmail o Outlook
In un contesto CRM, il venditore è colui che costruisce la relazione. Se la tua piattaforma invia follow-up da noreply@yourcrm.com, la deliverability cala e il prospect è confuso. Con l'invio per conto di, il tuo CRM chiama l'API Unipile utilizzando l'account collegato del venditore. Ogni email finisce nella casella di posta del prospect mostrando l'indirizzo reale del rappresentante.
IA bozza e invia dalla casella di posta dell'utente
Gli assistenti email basati sull'IA, che automatizzano la stesura di risposte, la pianificazione di follow-up o la sintesi di thread, necessitano dell'accesso in scrittura alla casella di posta dell'utente. Senza l'invio per conto terzi (on-behalf sending), l'IA può solo suggerire, non eseguire. Con un account collegato tramite l'API Unipile, il tuo assistente può inviare il messaggio approvato direttamente da Gmail o Outlook dell'utente con una singola chiamata API.
Gli agenti di supporto rispondono da una casella di posta condivisa di supporto
Le piattaforme di assistenza clienti spesso instradano i ticket attraverso una casella di posta condivisa come support@company.com. Quella casella di posta è essa stessa una casella di posta: deve essere collegata come un account. Con Unipile, la tua piattaforma può connettere quella casella di posta condivisa di Outlook o IMAP, consentendo a qualsiasi agente di inviare risposte che sembrano provenire direttamente dall'indirizzo di supporto ufficiale, con il contesto completo della conversazione preservato.
POST /api/v1/email l'endpoint gestisce account Gmail, Outlook e IMAP.Come funziona l'API di posta elettronica per conto di terzi (flusso OAuth 2.0)
L'invio di email per conto di un utente richiede tre cose: il consenso dell'utente, un token di accesso valido e una chiamata di invio tramite l'infrastruttura del provider. Ecco come funziona questo flusso in pratica e come Unipile lo astrae in una singola API unificata. Per un riferimento tecnico più ampio sugli endpoint di invio, i parametri e le differenze tra i provider, consulta il nostro completo Guida API per l'invio di e-mail.
L'utente concede l'autorizzazione OAuth
L'utente fa clic su "Collega la tua email" all'interno del tuo prodotto SaaS. Unipile li reindirizza alla schermata di consenso OAuth del loro provider: Google per gli utenti Gmail, Microsoft per gli utenti Outlook e Microsoft 365. L'utente accede e approva gli ambiti richiesti, che includono la possibilità di inviare email per suo conto. Nessuna password viene mai condivisa con la tua applicazione.
La tua app riceve un ID account collegato
Una volta che l'utente completa il flusso OAuth, Unipile memorizza il token di accesso in modo sicuro e restituisce un account_id alla tua applicazione. Questo è un identificatore stabile per la casella di posta collegata dell'utente. Memorizzi questo ID nel tuo database associato al record dell'utente. Tutte le operazioni email successive per questo utente fanno riferimento a questo account_id - non toccherai mai il token OAuth grezzo.
Inviare tramite l'infrastruttura del provider
Quando la tua applicazione necessita di inviare un'email, chiama POST /api/v1/email con l'account_id e il payload del messaggio. Unipile instrada la richiesta attraverso il provider corretto: Gmail API per gli account Google, Microsoft Graph API per gli account Outlook e Microsoft 365, e SMTP per gli account IMAP. L'email viene spedita dalla casella di posta dell'utente e appare nella sua cartella Posta inviata.
Esempi di codice
import richieste # account_id recuperato dopo che l'utente completa il flusso OAuth UNIPILE_DSN = "https://api1.unipile.com:13301" ACCESS_TOKEN = "IL_TUO_TOKEN_DI_ACCESSO" ID_ACCOUNT = "id_utente_dal_db" payload = { "account_id": ID_ACCOUNT, "a": [{ "nome_visualizzato": "Sarah Connor", "identificatore": "sarah@acme.com" }], "soggetto": "Facendo seguito alla nostra conversazione", "corpo": "Ciao Sarah, solo per fare il punto...
" response = requests.posta( f"{UNIPILE_DSN}/api/v1/email", json=payload, headers={"X-API-KEY": ACCESS_TOKEN} ) print(response.json()) # {"object": "EmailSent", "email_id": "..."}
// account_id recuperato dopo che l'utente ha completato il flusso OAuth const UNIPILE_DSN = "https://api1.unipile.com:13301"; const TOKEN_DI_ACCESSO = "IL_TUO_TOKEN_DI_ACCESSO"; const ID_ACCOUNT = "id_utente_dal_db"; const payload = { account_id: ID_ACCOUNT, a: [{ nome_display: "Sarah Connor", identificatore: "sarah@acme.com" }], soggetto: "Facendo seguito alla nostra conversazione", corpo: "Ciao Sarah, solo per fare il punto...
" }; const response = await fetch(`${UNIPILE_DSN}/api/v1/emails`, { metodo: "POST", intestazioni: { "X-API-KEY": TOKEN_DI_ACCESSO, "Content-Type": "application/json" }, corpo: JSON.stringere}); const dati = await risposta.json(); console.log(dati); // { oggetto: "EmailInviata", email_id: "..." }
API On-Behalf vs. Email Transazionale: La Differenza Chiave
Queste due categorie di API per le email risolvono problemi fondamentalmente diversi. Confonderle è l'errore più comune che i team commettono quando specificano un'integrazione email. Ecco come si confrontano in ogni dimensione che conta.
Inviare email per conto terzi con Unipile
Unipile fornisce un'unica API unificata che astrae Gmail, Outlook e IMAP dietro un'interfaccia coerente. Crei un'unica integrazione: Unipile gestisce i flussi OAuth specifici del provider, il refresh dei token, l'instradamento SMTP e la gestione degli errori per entrambi. Ecco cosa è disponibile per ogni provider.
API per inviare email per conto di un utente - FAQ
Domande comuni sull'invio di e-mail per conto terzi con Unipile
Sì, a condizione che l'utente conceda esplicitamente l'autorizzazione. L'invio di email per conto terzi si basa su OAuth 2.0 (per Gmail e Outlook) o sulla condivisione esplicita delle credenziali (per IMAP). In entrambi i casi, l'utente autorizza consapevolmente la tua applicazione a inviare dalla sua casella di posta. Questo è lo stesso meccanismo utilizzato da ogni principale client di posta elettronica e strumento di produttività.
I requisiti chiave di conformità sono:
- L'utente deve acconsentire attivamente prima che tu invii qualcosa per suo conto
- La vostra informativa sulla privacy deve dichiarare che accedete e inviate dalla casella di posta dell'utente.
- L'utente deve essere in grado di revocare l'accesso in qualsiasi momento (revoca OAuth o disconnessione account)
- Non devi inviare contenuti che violino i termini di servizio del provider (ad es. spam)
Non è legale per inviare dall'indirizzo di qualcuno senza il suo consenso. Il flusso di collegamento basato su OAuth di Unipile garantisce di avere sempre l'autorizzazione esplicita dell'utente prima di qualsiasi operazione di invio.
Il destinatario vede la dominio proprio dell'utente nel campo Da - non il dominio della tua piattaforma. Questo è il valore fondamentale dell'invio per conto terzi. Ad esempio, se un rappresentante di vendita con l'indirizzo john@acme.com ha collegato il proprio account Gmail, ogni email inviata tramite il tuo CRM tramite Unipile mostrerà Da: john@acme.com.
L'email viene spedita tramite il provider di posta elettronica effettivo dell'utente (API Gmail, Microsoft Graph o SMTP), il che significa:
- I record SPF passano perché l'IP mittente è autorizzato dal dominio dell'utente
- Le firme DKIM sono valide perché il provider firma con la chiave del dominio dell'utente
- L'allineamento DMARC passa per le stesse ragioni
Questa è fondamentalmente diversa da un'API transazionale in cui invii da un'infrastruttura condivisa e il destinatario vede il dominio della tua piattaforma.
Gli ambiti richiesti dipendono dal provider. Unipile gestisce la schermata di consenso OAuth automaticamente: i tuoi utenti visualizzano una normale finestra di dialogo di autorizzazione di Google o Microsoft. Gli ambiti precisi richiesti sono:
- Gmail: l'ambito dell'API di Gmail che consente l'invio di messaggi
https://mail.google.com/o il più limitatogmail.inviaambito se hai solo bisogno dell'accesso in invio) - Outlook / Microsoft 365: Microsoft Graph
Mail.Sendpunto di vista, piùMail.ReadWritese devi anche leggere o sincronizzare la casella di posta - IMAP: l'utente fornisce il suo hostname IMAP, la porta, il nome utente e la password o una password specifica per l'app (richiesta per account con autenticazione a due fattori abilitata)
Gli utenti possono revocare queste autorizzazioni in qualsiasi momento dalle impostazioni di sicurezza del loro account Google o Microsoft, o scollegando l'account collegato all'interno del tuo prodotto.
Sì. Qualsiasi casella di posta elettronica che possa essere autenticata tramite credenziali OAuth o IMAP può essere collegata come account Unipile. Questo include:
- Caselle di posta condivise in Microsoft 365 (ad es. support@company.com) - collegato tramite un account di servizio con le autorizzazioni delegate corrette
- Caselle di posta condivise e indirizzi di gruppo di Google Workspace con autorizzazioni "Invia per" configurate
- Qualsiasi alias e-mail gestito da una casella di posta accessibile tramite IMAP
Puoi anche personalizzare nome visualizzato nel campo Da utilizzando il from parametro nel payload dell'API, senza modificare l'indirizzo di invio sottostante.
Unipile gestisce il refresh dei token automaticamente per gli account Gmail e Outlook. I token di accesso OAuth scadono tipicamente dopo un'ora, ma il token di refresh ha una lunga durata. Quando Unipile rileva un token di accesso scaduto prima di un'operazione di invio, ne richiede silenziosamente uno nuovo utilizzando il token di refresh memorizzato; la tua applicazione non vede mai questo accadere e la chiamata di invio riesce normalmente.
L'unica volta in cui è necessario richiedere all'utente di autenticarsi nuovamente è se ha accesso revocato manualmente dalle impostazioni del loro account Google o Microsoft. Unipile segnala questo come una modifica dello stato dell'account che è possibile rilevare tramite webhook o eseguendo il polling dell'endpoint dell'account.
Avete ancora domande? Il nostro team è qui per aiutarvi.