LinkedIn
Instagram
WhatsApp
Telegramma
Calendario di Google
Partecipare alla comunità SlackCome leggere le email tramite API: una guida per sviluppatori su Accesso alla posta in arrivo
Ambito: Questa guida copre API di sincronizzazione per la lettura delle caselle di posta esistenti degli utenti - Gmail API, Microsoft Graph, IMAP e livelli unificati come Unipile. Questo è distinto dai servizi transazionali (SendGrid, Mailgun) che inviano email in uscita dal tuo dominio.
Costruisci prodotti che leggono le e-mail degli utenti programmaticamente. Da un singolo GET /api/v1/email chiamate ai webhook in tempo reale, questa guida copre ogni approccio con codice funzionante in Node.js, Python e cURL.
// Leggi email con un'unica chiamata API unificata
const response = await fetch(
'https://api3.unipile.com:PORT/api/v1/emails',
{
intestazioni: {
'X-API-KEY': process.env.UNIPILE_API_KEY,
'ID account': accountId
}
}
);
const { email } = await risposta.json();
// Stessa forma JSON per Gmail, Outlook e IMAP
email.per ciascunoemail => {
console.log(email.oggetto, email.da_partecipante);
});
Gmail, Outlook e IMAP
Che cos'è un'API di lettura e-mail?
Un'API di lettura email è un'interfaccia HTTP che consente alla tua applicazione di accedere, recuperare ed elaborare le email dalla casella di posta esistente di un utente, senza memorizzare password o creare integrazioni specifiche per il provider. È la base di qualsiasi prodotto che necessiti di visibilità sulla casella di posta: sincronizzazione CRM, assistenti AI per le email, automazione del supporto o archiviazione per la conformità.
A leggi email API espone endpoint per l'autenticazione contro la casella di posta di un utente (tramite credenziali OAuth 2.0 o IMAP), elenca i messaggi in arrivo, recupera i corpi completi delle email con allegati e sottoscrive eventi di consegna in tempo reale. Funziona sull'account Gmail, Outlook o IMAP esistente dell'utente - non un dominio che controlli. Questo lo distingue dalle API di email transazionali (SendGrid, Mailgun, Resend), che inviano email in uscita per conto della tua applicazione.
Connettiti alle caselle di posta esistenti degli utenti. Leggi, sincronizza e reagisci alle email in tempo reale. Autenticazione tramite OAuth 2.0 o IMAP. L'utente concede l'accesso alla propria casella di posta.
Invia email in uscita da un dominio che controlli. Usato per ricevute, notifiche, reset password. Nessun accesso alla casella di posta.
Perché la lettura programmatica delle email è importante
La capacità di leggere le email degli utenti tramite API sblocca una categoria di prodotti che erano semplicemente impossibili con solo SMTP. Ecco i quattro casi d'uso principali che guidano l'adozione nel 2026.
Sincronizzazione CRM e Vendite di Coinvolgimento
Gli strumenti di vendita devono vedere ogni thread di e-mail tra un rappresentante e un potenziale cliente, automaticamente, senza registrazione manuale. Un'API di lettura delle e-mail estrae le conversazioni direttamente dalla casella di posta del rappresentante e le sincronizza con il tuo CRM in tempo reale.
Agenti AI e Copilot per le Email
I modelli linguistici di grandi dimensioni necessitano di contesto. Fornendo al tuo agente AI un flusso in tempo reale di email in arrivo, puoi creare copiloti che abbozzano risposte, riassumono thread, estraggono elementi d'azione e danno priorità alle conversazioni automaticamente.
Automazione del supporto clienti
I team di supporto ricevono migliaia di email al giorno. Un'API di lettura delle email consente alla tua piattaforma di classificare le richieste in arrivo, instradarle alla coda corretta e attivare risposte automatiche, il tutto prima che un essere umano apra un ticket.
Conformità, Archiviazione e eDiscovery
I settori regolamentati devono conservare e indicizzare ogni email. Un'API per la lettura delle email fornisce l'accesso programmatico necessario per archiviare continuamente le caselle di posta, segnalare violazioni delle norme e produrre registrazioni di email su richiesta per revisioni legali.
API native per la lettura delle email: Gmail, Outlook e IMAP
Ogni provider di posta elettronica principale espone la propria API di lettura con endpoint, modelli di autenticazione e funzionalità diversi. Ecco come appare nella pratica ciascuno.
API Gmail
OAuth 2.0L'API Gmail è un'API REST basata sull'infrastruttura di Google. Utilizza utenti.messaggi.elenca per sfogliare una casella di posta e utenti.messaggi.get per recuperare un messaggio completo. Supporta notifiche push tramite Google Pub/Sub, rendendo il monitoraggio della casella di posta in tempo reale fattibile senza polling. Limite di frequenza: 250 unità di quota per utente al secondo.
# Elenco dei messaggi nella posta in arrivo (API di Gmail)
ricciolo -X OTTIENI \
"https://gmail.googleapis.com/gmail/v1/users/me/messages?labelIds=INBOX&maxResults=20" \
-H "Autorizzazione: Bearer ACCESS_TOKEN"
# Recupera una singola e-mail con il testo completo
ricciolo -X OTTIENI \
"https://gmail.googleapis.com/gmail/v1/users/me/messages/ID_MESSAGGIO?format=full" \
-H "Autorizzazione: Bearer ACCESS_TOKEN"
Microsoft Graph (Outlook e Microsoft 365)
OAuth 2.0Microsoft Graph è l'API unificata per tutti i servizi Microsoft 365, inclusi i singoli account Outlook, Exchange Online e le caselle di posta aziendali di Microsoft 365. Il /me/messaggi endpoint restituisce messaggi con il corpo completo in un'unica richiesta. La paginazione utilizza $salta e $sopra Parametri OData. Vedi il completo Guida all'integrazione delle e-mail con Microsoft Graph per i dettagli.
# Elenco dei messaggi nella posta in arrivo (Microsoft Graph)
ricciolo -X OTTIENI \
""https://graph.microsoft.com/v1.0/me/messages?\$top=20&\$filter=parentFolderId eq 'inbox'"' \
-H "Autorizzazione: Bearer ACCESS_TOKEN" \
-H "Content-Type: application/json"
# Recupera un singolo messaggio con corpo
ricciolo -X OTTIENI \
""https://graph.microsoft.com/v1.0/me/messages/MESSAGE_ID?\$select=subject,body,from,receivedDateTime"" \
-H "Autorizzazione: Bearer ACCESS_TOKEN"$seleziona e Accettare intestazioni.
IMAP
Protocollo UniversaleIMAP (Internet Message Access Protocol) è il protocollo email universale supportato praticamente da ogni server di posta. Non è un'API REST ma una connessione TCP stateful tramite la porta 993 (TLS). Emetti comandi come RECUPERA, RICERCA, e INATTIVO sulla connessione. Per un approfondimento, vedi il nostro Guida all'integrazione dell'API IMAP.
import imaplib, e-mail
#: Connessione e autenticazione
posta elettronica = imaplib.IMAP4_SSL('imap.example.com')
posta.Accedi('user@example.com', 'password_app')
posta.seleziona('POSTA IN ARRIVO')
# Alla ricerca di messaggi nascosti
stato, message_ids = posta.ricerca(Nessuno, 'INVISIBILE')
per msg_id in message_ids[0].spaccare():
_, data = posta.fetch(id_messaggio, '(RFC822)')
messaggio = email.messaggio_da_byte(dati[0][1])
print(messaggio'soggetto'], msg['da'])INATTIVO comando, che mantiene una connessione aperta e attende le notifiche del server. Ciò non scala facilmente oltre qualche centinaio di account concorrenti.Yahoo Mail, ProtonMail, Zoho e altri provider supportano tutti IMAP come soluzione universale di riserva, quindi sono coperti dall'approccio IMAP sopra descritto. Alcuni (come Yahoo) espongono anche API proprietarie limitate, ma nessuna eguaglia le capacità dell'API di Gmail o di Microsoft Graph. Per la maggior parte dei prodotti multi-provider, IMAP è la soluzione universale di riserva per qualsiasi casella di posta non coperta da Gmail o Outlook OAuth. API email unificata gestisce questa negoziazione automaticamente.
La complessa complessità della lettura delle email su larga scala
Costruire un'integrazione API per la lettura delle e-mail contro un singolo provider per una demo richiede un pomeriggio. Costruirne una che funzioni in modo affidabile su tutti i provider su scala di produzione è una sfida completamente diversa. Ecco cosa comporta effettivamente l'ingegneria.
Flusso OAuth per provider
Ogni provider ha la propria implementazione OAuth 2.0, requisiti per la schermata di consenso, ambiti e ciclo di vita dei token. Il supporto di Gmail e Outlook significa mantenere due app OAuth separate, due console per sviluppatori, due strategie di rinnovo dei token e due set di requisiti di conformità (Google CASA Tier 2, Microsoft Publisher Verification).
Differenze di paginazione
Ogni provider gestisce la paginazione in modo diverso. Gmail utilizza token di pagina opachi. Microsoft Graph utilizza OData. $salta e nextLink cursor. IMAP utilizza intervalli di UID numerici. L'implementazione di un'astrazione di paginazione coerente tra tutti e tre richiede un codice adattatore non banale.
Analisi MIME
Le email arrivano come documenti MIME grezzi con limiti multipart annidati, codifica base64 o quoted-printable, set di caratteri multipli e allegati inline. Gmail restituisce parti codificate in base64url. IMAP restituisce RFC 822 grezzo. Nessuno dei due ti fornisce un corpo di testo normale pulito senza analizzare l'intero albero MIME.
Limiti di frequenza e backoff
Gmail applica 250 unità di quota per utente al secondo (un elenco costa 5 unità, recuperare costa 5 unità). Microsoft Graph applica una limitazione di 10.000 richieste ogni 10 minuti per app per tenant. Entrambi restituiscono errori 429 che richiedono un backoff esponenziale con jitter. Con 1.000 account collegati, la gestione dei limiti di frequenza diventa un problema ingegneristico a tutti gli effetti.
In Tempo Reale: Webhook, Polling e IDLE a confronto
Ricevere notifiche all'arrivo di nuove email richiede meccanismi completamente diversi per ciascun provider. Gmail utilizza le sottoscrizioni push di Google Pub/Sub che devono essere rinnovate ogni 7 giorni. Microsoft Graph utilizza le sottoscrizioni di notifica delle modifiche con una durata massima di 4.230 minuti. IMAP utilizza il comando IDLE, che mantiene aperta una connessione TCP persistente per account.
Incoerenze di filato tra provider
Gmail raggruppa nativamente i messaggi in thread. Microsoft Graph ha un campo conversationId ma i thread si comportano in modo diverso da Gmail. IMAP non ha threading nativo: ricostruisci i thread abbinando manualmente gli header References e In-Reply-To. La creazione di una vista di thread unificata cross-provider richiede una logica di normalizzazione significativa.
Architettura API di lettura email: 3 approcci a confronto
Non esiste un'unica architettura "corretta" per la lettura delle e-mail. L'approccio giusto dipende da quanti provider è necessario supportare, dalle risorse di ingegneria disponibili e dai requisiti di scalabilità. Ecco un confronto onesto.
| Approccio | Pro | Conservare | Quando usare |
|---|---|---|---|
| API del provider diretto Gmail API, Microsoft Graph |
Livello gratuito, accesso completo alle funzionalità, nessuna latenza intermedia | Configurazione OAuth per provider, analisi MIME, gestione separata dei limiti di frequenza, nessuna normalizzazione tra provider | Solo fornitore unico |
| IMAP self-ospitato imaplib, node-imap |
Protocollo universale, funziona con qualsiasi casella di posta, nessuna app OAuth richiesta | Connessioni TCP stateful, nessuna notifica push (polling o IDLE), gestione del connection pool, lento su larga scala | Legacy / solo on-premise |
| API unificata per la lettura delle email Unipile |
Un endpoint per tutti i provider, risposta JSON normalizzata, OAuth gestito, webhook unificati, logica di ripetizione integrata | Costo aggiuntivo per chiamata API per account collegato, dipendenza esterna | Prodotti multi-provider |
Se tutti gli utenti del tuo prodotto utilizzano Gmail, integrati direttamente con l'API di Gmail. Otterrai la parità di funzionalità completa, nessun costo aggiuntivo e l'accesso a funzionalità specifiche di Gmail come etichette, thread e push Pub/Sub.
Server di posta on-premises, distribuzioni Exchange aziendali senza accesso all'API Graph o qualsiasi scenario in cui OAuth non sia disponibile. Utilizzare IMAP come soluzione di ripiego, non come strategia principale per i nuovi prodotti.
Quando i tuoi utenti hanno caselle di posta Gmail, Outlook e IMAP e necessiti di un'unica API di lettura email coerente per tutte, uno strato unificato come Unipile elimina completamente il problema dell'integrazione N-provider.
Leggere le e-mail con l'API Unificata di lettura e-mail di Unipile
Unipile astrae API di Gmail, Microsoft Graph e IMAP dietro un'unica API di lettura delle email. Un flusso OAuth, un endpoint, una struttura JSON normalizzata, indipendentemente dal provider su cui si trova la casella di posta del tuo utente. Ecco come leggere la tua prima casella di posta in meno di 5 minuti.
Genera un URL di autenticazione ospitato dalla tua dashboard Unipile. Invia questo link al tuo utente: completa il flusso di consenso OAuth per il suo provider (credenziali Gmail, Outlook o IMAP) sulla pagina ospitata di Unipile. Nessuna configurazione dell'app OAuth, nessuna configurazione dell'URI di reindirizzamento da parte tua. Vedi la guida API unificata per email per il flusso di autenticazione completo.
# Genera un link di autenticazione ospitato per il tuo utente
ricciolo -X POST \
"https://api3.unipile.com:PORT/api/v1/hosted/accounts/link" \
-H "X-API-KEY: LA_TUA_CHIAVE_API" \
-H "Content-Type: application/json" \
-d '{"type":"EMAIL","name":"user@example.com","success_redirect_url":"https://yourapp.com/connected"}'
Risposta #: { "url": "https://auth.unipile.com/..." }
# Invia questo URL al tuo utente: dovrà completare la procedura OAuth sul proprio providerUna volta che l'utente ha collegato il proprio account, chiama l'endpoint delle e-mail con il suo account_id. La risposta è identica sia che la casella di posta sottostante sia Gmail, Outlook o IMAP.
#: Elenco delle e-mail in arrivo (funziona con Gmail, Outlook e IMAP)
ricciolo -X OTTIENI \
"https://api3.unipile.com:PORT/api/v1/emails?account_id=ACCOUNT_ID&limit=50" \
-H "X-API-KEY: LA_TUA_CHIAVE_API"
# Filtra per cartella
ricciolo "...?account_id=ACCOUNT_ID&cartella=POSTA_IN_ENTRATA&limite=50" -H "X-API-KEY: LA_TUA_CHIAVE_API"
#: solo filtra non letti
ricciolo "...?account_id=ACCOUNT_ID&unread=true" -H "X-API-KEY: LA_TUA_CHIAVE_API"Recupera un'email completa tramite ID. Unipile restituisce un oggetto decodificato e normalizzato con corpo in testo normale, corpo HTML e metadati degli allegati, senza richiedere parsing MIME da parte tua.
# Recupera una singola e-mail con il testo completo e gli allegati
ricciolo -X OTTIENI \
"https://api3.unipile.com:PORT/api/v1/emails/EMAIL_ID" \
-H "X-API-KEY: LA_TUA_CHIAVE_API"
Campi di risposta # (sempre normalizzati):
# { "id", "oggetto", "data", "mittente", "destinatari",
# "corpo", "corpo_semplice", "allegati": [{ "id", "nome_file", "dimensione" }] }Registra un endpoint webhook nella tua dashboard Unipile. Unipile astrae Pub/Sub di Gmail, le notifiche di modifica di Microsoft Graph e IMAP IDLE in un unico email.ricevuto event. Nessun rinnovo di abbonamento, nessun pool di connessioni IDLE da gestire.
// Unipile chiama il tuo endpoint quando arriva una nuova email
// Stesso evento per gli utenti Gmail, Outlook e IMAP
app.posta('/webhooks/email', (req, res) => {
const { evento, id_account, id_email } = req.body;
se (evento === 'email.ricevuto') {
// Recupera tutti i dettagli dell'email
elaboraNuovaEmail(id_account, id_email);
}
res.statoInvio(200);
});La Guida completa all'API delle email copre in dettaglio autenticazione, endpoint, paginazione, download di allegati, sicurezza e conformità.
Lettura Email: Esempi di Codice per Lingua
Snippet pronti per la produzione per la lettura di email con l'API unificata di lettura email di Unipile. Tutti gli esempi leggono da account Gmail, Outlook e IMAP con lo stesso codice.
import fetch from 'node-fetch';
const BASE = 'https://api3.unipile.com:PORT/api/v1';
const CHIAVE_API = process.env.CHIAVE_API_UNIPILE!;
interfaccia Email {
identificatore stringa;
oggetto: stringa;
data: stringa;
da_partecipante: { nome_visualizzato: stringa; identificatore: stringa };
body: stringa;
Nome e cognome stringa;
allegati: { id: stringa; nome del file: stringa; dimensione: numero }[];
}
// Elenca le email della casella di posta in arrivo - funziona per Gmail, Outlook e IMAP
async function elencaEmail(accountID: stringa, limite = 50) {
const res = await fetch(
`${BASE}/emails?account_id=${accountId}&limit;=${limit}&folder;=INBOX`,
{ intestazioni: { 'X-API-KEY': CHIAVE_API } }
);
const dati = await res.json();
return data.elementi come Email[];
}
// Recupera una singola email con corpo completo + allegati
async function OttieniEmail(emailId: stringa) {
const res = await fetch(`${BASE}/emails/${emailId}`,
{ intestazioni: { 'X-API-KEY': CHIAVE_API } }
);
return await res.json() come Email;
}
// Utilizzo
const e-mail = await elencaEmail('acc_01abc...');
email.per ciascuno(e => console.log(e.oggetto, e.dal_partecipante.identificatore));import os
import richieste
BASE = "https://api3.unipile.com:PORT/api/v1"
INTÈSTAZIONI = {"X-API-KEY": os.environ["UNIPILE_API_KEY"]}
def elenco_email(id_account: str, limite: int = 50) -> elenco:
"""Elenca le email della posta in arrivo - funziona per Gmail, Outlook e IMAP."""
rispondi = richieste.ottenere(
{BASE}/email",
headers=HEADERS,
parametri={
"account_id": id_account,
"limite"limite,
"cartella": "Posta in arrivo",
},
)
resp.raise_for_status()
return resp.json()["articoli"]
def ottenere_email(email_id: str) -> dict:
"""Recupera un'email singola con corpo e allegati."""
rispondi = richieste.ottenere("{BASE}/emails/{email_id}", headers=HEADERS)
resp.raise_for_status()
return resp.json()
# Utilizzo
e-mail = elenco_email("acc_01abc...")
per e-mail in email:
print(email["soggetto", email["dal_partecipante"]["identificatore"])
#: recupera il testo completo del corpo del messaggio per la prima e-mail
pieno = ottenere_email(email0]["id"])
print(pieno"corpo_piano"])pacco principale
import (
"codifica/json"
"fmt"
"net/http"
"os"
)
tipo Email struttura {
ID stringa `json:"id"`
Oggetto stringa `json:"soggetto"`
CorpoPiano stringa `json:"corpo_in_chiaro"`
}
tipo ElencoRisposta struttura {
Articoli []Email `json:"elementi"`
}
funzione elencaEmail(accountID string) ([]Email, errore) {
url := "https://api3.unipile.com:PORT/api/v1/emails?account_id=" + ID account
richiesta, _ := http.Nuova Richiesta("PRENDI", url, nullo)
req.Header.Imposta("X-API-KEY", os.Getenv("UNIPILE_API_KEY"))
resp, err := http.DefaultClient.Fare(richiesta)
se errore != nullo { return nullo, errore }
rimandare resp.Body.Chiudere()
variabile risultato ElencoRisposta
json.Decodificatore(resp.Body).Decodifica(&risultato)
return risultato.Articoli, nullo
}
funzione principale() {
email, _ := elencaEmail("acc_01abc...")
per _, e := gamma email {
formato.Stampare(e\.Oggetto)
}
}Lettura delle email in tempo reale: Webhook vs Polling
Sapere quando arriva una nuova email è importante quanto poterla leggere. Ci sono tre meccanismi disponibili, ognuno con caratteristiche operative molto diverse su larga scala.
Sondaggio
La tua applicazione chiama l'endpoint di elenco e-mail con un timer (ogni 30 secondi, ogni 5 minuti). Semplice da implementare ma consuma quote, introduce latenza e non è scalabile oltre una manciata di account.
Webhook del provider nativo
Le notifiche push di Gmail Pub/Sub e Microsoft Graph inviano eventi al tuo server immediatamente. Veloci ed efficienti in termini di quote, ma ognuno richiede una configurazione separata, una logica di rinnovo separata e schemi di eventi diversi.
Webhook Unificati Unipile
Unipile astrae tutti i meccanismi di push del provider dietro un unico email.ricevuto event. Un endpoint riceve notifiche per account Gmail, Outlook e IMAP indistintamente, con il rinnovo automatico degli abbonamenti gestito internamente.
Sotto il cofano, Unipile gestisce sottoscrizioni Gmail Pub/Sub, sottoscrizioni di notifiche di modifica Microsoft Graph e connessioni IMAP IDLE, per account collegato, rinnovate automaticamente. La tua applicazione registra un URL webhook e riceve un evento normalizzato indipendentemente dal provider sottostante.
Sicurezza e Conformità nella Lettura delle E-mail degli Utenti
L'accesso alle email degli utenti comporta significative responsabilità in materia di sicurezza e legali. Ecco le quattro aree che devi affrontare prima di implementare un'API di lettura email in produzione.
Minimizzazione dell'ambito OAuth
Richiedi sempre l'ambito OAuth minimo necessario. Per la lettura delle email, usa scope di sola lettura - non richiedere mai permessi di invio o composizione se la tua applicazione necessita solo dell'accesso alla posta in arrivo. L'ambito di sola lettura di Gmail è gmail.solodlettura. Microsoft Graph equivalent è Posta.Leggi. Richiedere autorizzazioni ampie innesca processi di revisione più severi da parte di Google e Microsoft e riduce la fiducia degli utenti nella schermata di consenso.
Token Storage Best Practices
I token di accesso e di refresh OAuth sono credenziali. Memorizzali crittografato a riposo Utilizzare AES-256 o equivalente, mai in chiaro nel database. Ruotare le chiavi di cifratura secondo una pianificazione. Non registrare mai i token nei log dell'applicazione. Implementare la revoca dei token quando un utente disconnette il proprio account: chiamare l'endpoint di revoca del provider, non eliminare semplicemente il record nel database.
GDPR e residenza dei dati
I corpi delle email spesso contengono dati personali coperti dal GDPR. Devi documentare nella tua privacy policy esattamente quali dati delle email raccogli, conservi, elabori e per quanto tempo. Implementa un flusso di cancellazione dei dati che rimuova il contenuto delle email quando un utente richiede la cancellazione. Se memorizzi il contenuto delle email nella tua infrastruttura, considera i requisiti di residenza dei dati per i clienti UE.
Verifica di Google CASA e Microsoft Publisher
Applicazioni che richiedono ambiti Gmail sensibili (incluso gmail.solodlettura) deve completare Google's CASA Livello 2 valutazione di sicurezza prima di essere autorizzati oltre il limite di test di 100 utenti. Microsoft richiede la verifica dell'editore per le app che richiedono determinati ambiti di Graph. Entrambi i processi richiedono settimane, pianifica di conseguenza prima della data di lancio. L'utilizzo di Unipile eredita queste certificazioni dal livello della piattaforma.
Unipile gestisce la certificazione di Livello 2 CASA di Gmail, la verifica di Microsoft Publisher, l'audit SOC 2 di Tipo II e gli accordi di elaborazione dati del GDPR a livello di piattaforma. I prodotti costruiti su Unipile ereditano queste certificazioni anziché completarle in modo indipendente.
Prezzi API di lettura email: piani gratuiti e modelli di costo
I piani gratuiti per le API dei provider nativi sono generosi su piccola scala, ma i costi nascosti emergono quando è necessario supportare più provider, gestire il rinnovo dei token su larga scala o raggiungere i limiti di frequenza. Ecco un'analisi onesta.
| Fornitore | Piano gratuito | Modello di costo | Limite di frequenza | Costi nascosti |
|---|---|---|---|---|
| API Gmail | Gratis con quote | Unità di quota per richiesta. Nessuna fatturazione per account | 250 unità/sec/utente, 1 miliardo di unità/giorno | Revisione CASA Livello 2, parsing MIME, logica di rinnovo Pub/Sub |
| Microsoft Graph | Gratuito con limitazioni | Incluso nell'abbonamento a Microsoft 365. Nessun costo per chiamata | 10.000 richieste/10 minuti/app/tenant | Processo di verifica dell'editore, rinnovo dell'abbonamento, app OAuth per tenant |
| IMAP (auto-ospitato) | Protocollo gratuito | Nessun costo API. Costo dell'infrastruttura per pool di connessione | Specifico per il provider, ~10-20 connessioni/account | Infrastruttura server, gestione connessioni IDLE, nessun supporto push |
| Unipile | 7 giorni di prova gratuita | Per account collegato al mese. Vedi API email gratuita | Gestito internamente, logica di riprova integrata | Costo chiamata API per account - compensato dall'ingegneria OAuth/MIME eliminata |
Iniziando con un'API di email di lettura gratuita? L'API di Gmail e Microsoft Graph offrono accesso gratuito entro i limiti di quota. Unipile offre una prova gratuita di 7 giorni senza richiesta di carta di credito, che copre account collegati Gmail, Outlook e IMAP.
Inizia la prova gratuitaErrori comuni nella creazione di un'integrazione per le email lette
Questi sono gli errori che causano costantemente incidenti di produzione per i team che implementano la loro prima integrazione API di lettura email. Imparali prima che ti succedano.
Le 250 unità di quota al secondo per utente di Gmail sembrano generose finché non si hanno 500 account e si necessita di una sincronizzazione iniziale della posta in arrivo. Elencare 500 messaggi costa 2.500 unità; recuperare ogni messaggio completo costa altre 2.500. Le sincronizzazioni iniziali per grandi caselle di posta possono esaurire le quote giornaliere in poche ore.
I token di aggiornamento OAuth scadono silenziosamente: Google li revoca dopo 6 mesi di inattività, dopo un cambio di password o quando un utente revoca l'accesso dalle impostazioni del proprio Account Google. Se la logica di aggiornamento del token non rileva un errore 401 e lo segnala all'utente, l'applicazione smetterà semplicemente di leggere le email senza alcun errore visibile.
ultima_sincronizzazione_alle timestamp e avviso quando supera l'intervallo di sincronizzazione previsto.Le etichette di Gmail e le cartelle IMAP non sono concetti equivalenti. Quelle di Gmail INBOX L'etichetta non include i messaggi che sono stati archiviati (rimossi dalla Posta in arrivo ma non eliminati). La cartella Posta in arrivo di Microsoft Graph esclude la Posta in arrivo in primo piano rispetto ad altre suddivisioni del riquadro, a meno che non si effettuino ricerche in entrambe. Gli utenti di Teams spesso si rendono conto che mancano 20-40% messaggi a causa di presupposti errati sulle cartelle.
TUTTO messaggi (non solo POSTA IN ARRIVO) e filtraggio per data da parte tua.I corpi delle email arrivano in una vasta gamma di codifiche di caratteri: UTF-8, ISO-8859-1, Windows-1252, Shift-JIS. Gmail restituisce parti codificate in base64url. IMAP restituisce parti codificate in quoted-printable. La decodifica di una codifica come un'altra produce testo del corpo corrotto che è invisibile nel tuo ambiente di test locale (che probabilmente invia solo email ASCII).
Content-Transfer-Encoding e codifica nuovamente in UTF-8. Testa specificamente con contenuti di email in giapponese, arabo e con molti emoji.Costruire una visualizzazione unificata delle conversazioni tra account Gmail, Outlook e IMAP richiede la normalizzazione di tre modelli di threading completamente diversi. Gmail ha ID di conversazione nativi. Outlook ha ID di conversazione che si comportano diversamente. IMAP non ha threading nativo – si ricostruiscono le conversazioni da ID messaggio, Riferimenti, e In-Reply-To intestazioni, che non sono sempre presenti o corrette.
API per la lettura delle email - Domande frequenti
Le domande più frequenti degli sviluppatori che integrano per la prima volta un'API per la lettura di email.
gmail.solodlettura ambito, ottenere un token di accesso tramite consenso OAuth, quindi chiamare GET /gmail/v1/users/me/messages elencare messaggi e GET /users/me/messages/{id}?format=full per recuperare singole email. I messaggi vengono restituiti come parti MIME codificate in base64url che è necessario decodificare.GET /api/v1/email) che restituisce JSON normalizzato per account Gmail, Outlook e IMAP. Autentichi gli utenti una volta tramite un link OAuth ospitato e Unipile gestisce i flussi OAuth specifici del provider, il parsing MIME e l'astrazione dei webhook in tempo reale dietro un'unica interfaccia coerente. Vedi il nostro Guida alle API per le e-mail per riferimento completo./messaggi/{id}/allegati. IMAP richiede l'analisi dell'albero MIME per identificare le parti degli allegati. Con Unipile, i metadati degli allegati (nome file, dimensione, tipo MIME) sono inclusi nella risposta dell'email e il contenuto degli allegati è disponibile tramite un endpoint dedicato, senza richiedere l'analisi MIME.email.ricevuto evento webhook che si attiva per account Gmail, Outlook e IMAP con gestione automatica degli abbonamenti gestita internamente.Ritenta dopo header. Implementa il backoff esponenziale con jitter per l'affidabilità della produzione. I limiti IMAP sono specifici del provider, in genere 10-20 connessioni simultanee per account.
IT 
EN 
FR 
ES 
DE 
BR 
NL 
PL 
TR