API de sincronização de e-mail para integração perfeita de software

Unipile - API de Sincronização de E-mail Hero
API de Sincronização de E-mail - Guia 2026

Email API de sincronização: Como Funciona a Sincronização de E-mails para Produtos SaaS

Crie recursos SaaS que sincronizam caixas de entrada de usuários em tempo real. Conecte Gmail, Outlook e IMAP através de uma única API de sincronização de e-mail, com webhooks, fluxos OAuth e acesso completo a pastas incluídos.

sync-emails.js
const UnipileClient = require('@unipile/node-sdk'); const client = new UnipileClient({ dsn: process.env.UNIPILE_DSN, token: process.env.UNIPILE_TOKEN }); // Buscar emails sincronizados da conta vinculada const e-mails = await cliente.email.listaremail({ account_id: 'acc_gmail_xyz', pasta: 'Caixa de entrada', limite: 50 }); // Tempo real: registrar webhook await client.webhook.create({ url: 'https://seusite.com/webhooks/email', eventos: ['email.novo', 'email.ler'] });
Sincronização unificada entre Gmail, Outlook e IMAP
Suportes: Gmail Perspectivas IMAP
Definição

O que é uma API de sincronização de e-mail?

Um API de sincronização de e-mail é uma interface programática que permite que seu aplicativo espelhe continuamente a caixa de correio de um usuário - lendo novas mensagens, rastreando alterações de status (lido/não lido, movido, excluído) e refletindo a estrutura de pastas - sem que o usuário exporte dados manualmente. Ao contrário de uma API somente de envio, uma API de sincronização de e-mail mantém uma réplica ao vivo e bidirecional da caixa de entrada dentro do seu produto.

No nível do protocolo, cada provedor expõe seu próprio primitivo de sincronização: o Gmail usa histórico.listar with a idHistórico cursor, o Microsoft Graph usa consultas delta em /mensagens/delta endpoint, e servidores IMAP padrão suportam o IDLE comando para notificações push. A API unificada de sincronização de e-mail como a Unipile abstrai esses três protocolos por meio de um único endpoint, sua equipe escreve a lógica de sincronização uma vez e a distribui para todos os provedores.

Se você está construindo um CRM, uma ferramenta de engajamento de vendas, um assistente de e-mail com IA ou qualquer SaaS que precise de dados de caixa de entrada em tempo real, uma API de sincronização de e-mail é a base. Para o envio de e-mails transacionais (redefinições de senha, recibos), essa é uma categoria diferente - veja Nosso guia completo da API de e-mail ou nosso dedicado síncrono vs. transacional comparação.

Espelhamento de caixa de entrada em tempo real
Gmail, Outlook e IMAP
OAuth 2.0 + atualização de token
Webhooks para novos e-mails
Sincronização de Pasta + Rótulo
Conceitos

Sincronização de E-mail vs. Envio de E-mail: Por que a Distinção Importa

Desenvolvedores frequentemente confundem APIs de sincronização de e-mail com APIs de e-mail transacional. Elas servem a propósitos opostos. Escolher a categoria errada atrasa sua arquitetura em semanas.

O que você está construindo
API de Sincronização de Email

Lê e espelha a caixa de entrada existente de um usuário em seu aplicativo. Requer que o usuário autorize o acesso à sua conta (credenciais OAuth ou IMAP). Seu aplicativo se torna um leitor secundário da caixa de entrada deles.

  • Lê mensagens recebidas e enviadas
  • Faixas lidas/não lidas, rótulos, pastas
  • Notificações de Webhook para novos e-mails
  • Acesso completo à thread e ao anexo
  • Delta sync - busca apenas alterações
  • Usado por: CRMs, ferramentas de engajamento de vendas, assistentes de e-mail com IA, centrais de atendimento, arquivamento de e-mail, análises de caixa de entrada.

    Categoria diferente
    API de E-mail Transacional

    Envie e-mails gerados pelo sistema do seu próprio domínio. Nenhuma autorização do usuário é necessária. Você se autentica como remetente (API key), não como o usuário. Exemplos: SendGrid, Mailgun, Resend, Amazon SES.

  • Apenas saída (redefinições de senha, recibos)
  • Autenticado via chave de API, não OAuth
  • Focado em taxa de entrega e SPF/DKIM
  • Sem acesso de leitura à caixa de entrada
  • Nenhum consentimento OAuth do lado do usuário é necessário
  • Unipile NÃO está nesta categoria. Unipile é o lado de sincronização - leitura e espelhamento de caixas de entrada de usuários via OAuth.

    Casos de uso

    Quem Precisa de uma API de Sincronização de E-mail?

    Qualquer produto SaaS que precise exibir, analisar ou agir sobre o e-mail de entrada de um usuário depende de uma API de sincronização de e-mail. Estes são os cinco casos de uso mais comuns que vemos em produção.

    Sincronização de E-mail do CRM

    Registre automaticamente todos os e-mails de entrada e saída no registro de contato correto. Os representantes de vendas param de copiar e colar e-mails; o CRM se torna o sistema de registro em tempo real. Nenhum encaminhamento manual de CCO é necessário.

    Guia da API de E-mail
    Engajamento de Vendas

    Rastreie taxas de resposta, detecte respostas de ausência e acione sequências de acompanhamento com base em eventos da caixa de entrada. Uma API de sincronização de e-mail dá às suas sequências uma consciência em tempo real do que está acontecendo na caixa de entrada do prospect.

    Enviar e-mail programaticamente
    Agentes de E-mail de IA

    Alimente um fluxo de e-mail ao vivo em um agente de LLM que redige respostas, categoriza mensagens recebidas, extrai itens de ação ou encaminha tickets. O agente precisa de um feed de sincronização contínuo, não de uma exportação única. Uma API de sincronização de e-mail em tempo real é obrigatória.

    Ler emails programaticamente
    Integração com Helpdesk

    Converta e-mails de clientes em tickets de suporte automaticamente, incluindo todo o contexto da conversa e anexos. Sincronize o status do ticket de volta quando o agente responder, para que a caixa de entrada do cliente reflita o fluxo de resolução.

    Compare provedores de API de e-mail
    Arquivamento de E-mail

    Capture todos os e-mails de entrada e saída para fins de conformidade, descoberta legal ou análise. Uma API de sincronização de e-mail permite que você crie um arquivo consultável de todas as comunicações corporativas sem tocar diretamente no servidor de e-mail.

    Nível gratuito de API de e-mail
    Análise de Caixa de Entrada

    Analise o volume de e-mails, tempos de resposta, padrões de conversação e sentimento em várias contas vinculadas de uma equipe. As equipes de marketing, operações e finanças usam análises de caixa de entrada para medir a qualidade da comunicação e identificar gargalos.

    Guia completo da API de e-mail
    Por Baixo do Capô

    Como a Sincronização de E-mails Funciona: OAuth, Delta Sync e Webhooks

    Uma API de sincronização de e-mail é mais do que um endpoint de leitura. É um pipeline com estado que autentica usuários, mantém a validade de tokens, rastreia o estado da caixa de correio e entrega alterações em tempo quase real. Veja o que acontece em cada camada.

    1
    Fluxo de Autorização OAuth 2.0

    O usuário clica em "Conectar sua caixa de entrada" no seu aplicativo. Ele é redirecionado para a tela de consentimento do Google ou da Microsoft, onde aprova os escopos que seu aplicativo solicita. Para o Gmail, isso significa gmail.somente leitura ou gmail.modificar; para o Outlook significa Mail.Read ou Mail.ReadWrite. Após o consentimento, seu aplicativo recebe um token de acesso (válido por 1 hora para Google, 1 hora para Microsoft) e um token de atualização (de longa duração). Contas IMAP usam nome de usuário + senha ou OAuth, dependendo da configuração do provedor.

    2
    Snapshot Inicial da Caixa de Correio

    Na primeira sincronização, a API de sincronização de e-mail executa um preenchimento completo: ela busca a lista de pastas (INBOX, Enviado, Rascunhos, rótulos personalizados) e busca mensagens recentes até uma profundidade de histórico configurável. Para o Gmail, isso usa usuários.mensagens.listar com paginação. Para o Microsoft Graph, ele usa GET /me/messages. Para IMAP, ele emite um SELECIONAR CAIXA DE ENTRADA seguido de um BUSCAR intervalo. O snapshot fornece ao seu banco de dados seu estado de linha de base, incluindo IDs de mensagem e agrupamentos de tópicos.

    3
    Delta Sync - Busque Apenas o Que Mudou

    Após o snapshot inicial, verificar repetidamente a caixa de correio completa desperdiçaria cota e tornaria seu aplicativo lento. A sincronização delta é a solução. O Gmail oferece um idHistórico cursor: você chama usuários.histórico.lista com o último conhecido idHistórico e receber apenas as alterações (novas mensagens, alterações de rótulo, exclusões) desde aquele ponto. O Microsoft Graph usa GET /me/messages/delta with a $deltaToken. O IMAP usa BUSCAR UID with a ALTERADO DESDE modificador (extensão CONDSTORE). Este sincronização delta o padrão mantém as chamadas de API mínimas, mesmo para caixas de correio de alto volume.

    4
    Atualização de Token e Manutenção de Sessão

    Os tokens de acesso expiram. Sua infraestrutura de sincronização de e-mail deve detectar 401 Não autorizado respostas, use o token de atualização para obter um novo token de acesso do Google ou da Microsoft e tente novamente a solicitação falhada. Isso deve acontecer de forma transparente, sem interromper a sessão do usuário. Os próprios tokens de atualização podem ser revogados - pelo usuário, por uma política de admin ou após 6 meses de inatividade (Google) - portanto, seu sistema precisa detectar a revogação e solicitar ao usuário que reautorize.

    5
    Webhooks para Notificações em Tempo Real

    A verificação em intervalo introduz latência - uma verificação de 30 segundos significa que os e-mails podem estar desatualizados em até 30 segundos. Para recursos de caixa de entrada em tempo real, a API de sincronização de e-mail deve suportar notificações push. O Gmail usa o Google Cloud Pub/Sub: você registra um tópico e o Gmail publica uma notificação sempre que idHistórico avanços. O Microsoft Graph usa notificações de alteração em /me/mailFolders/inbox/messages resource. Uma API unificada de sincronização de e-mail (como a Unipile) normaliza isso em um único evento de webhook - email.novo entregue ao seu endpoint independentemente do provedor.

    Unipile - APIs Nativas de Sincronização de E-mail
    Análise Profunda do Fornecedor

    APIs Nativas de Sincronização de E-mail: Gmail, Microsoft Graph e IMAP

    Cada um dos três provedores de e-mail expõe um primitivo de sincronização diferente. Entender as diferenças mostra por que construir uma API de sincronização de e-mail multiprovedor do zero leva meses, não dias.

    Logo do Gmail Gmail - histórico.lista + Pub/Sub Contas do Google Workspace e pessoais

    O modelo de sincronização do Gmail é construído em torno do idHistórico cursor. Após sua sincronização inicial, cada chamada subsequente de usuários.histórico.lista retorna apenas alterações desde seu último conhecido idHistórico - novas mensagens, adição de rótulos, remoção de rótulos e exclusões.

    Para push em tempo real, o Gmail exige que você configure um tópico do Google Cloud Pub/Sub e chame usuários.assistir para registrá-lo. O Gmail publica então uma notificação (contendo um novo idHistórico) ao seu tópico sempre que a caixa de correio muda. Seu worker assina o tópico e chama histórico.listar para buscar as alterações reais.

    Limites de taxas: 1 bilhão de unidades de cota por dia por projeto, com limites por usuário. usuários.mensagens.obter custa 5 unidades; usuários.histórico.lista custa 2 unidades. Para um aplicativo multi-inquilino, o gerenciamento de cotas se torna uma preocupação em tempo integral. Veja o guia da API de e-mail para mais.

    gmail-delta-sync.py
    from googleapiclient.discovery import construir Sincronização Delta # usando o cursor historyId def buscar_alterações(serviço, id_histórico): resultado = service.users().history().list( userId="eu, idDoInícioDoHistórico=id_historico, tiposDeHistória=[ 'mensagemAdicionada', 'mensagemExcluída', 'rótuloAdicionado' ] ).executar() return resultado.obter('história', [])
    Logotipo do Outlook e Microsoft 365 Outlook / Microsoft 365 - Consultas Delta do Graph Outlook Pessoal e Exchange Online / M365

    Microsoft Graph usa consultas delta no /eu/mensagens/delta endpoint. A primeira chamada retorna uma página inteira de mensagens mais um @odata.deltaLink. Chamadas subsequentes a esse delta link retornam apenas mensagens alteradas desde a chamada anterior - itens novos, modificados e excluídos.

    Para push em tempo real, O Microsoft Graph suporta notificações de alteração via webhooks. Você registra uma assinatura em /me/mailFolders/inbox/messages with a urlDeNotificação. A Microsoft envia um POST para o seu URL quando as mensagens mudam. As assinaturas devem ser renovadas a cada 4230 minutos (cerca de 3 dias) ou expiram.

    Observação: Isso cobre tanto contas pessoais do Outlook quanto Microsoft 365 / Exchange Online - eles usam a mesma Graph API. Veja a Guia de integração de email do Microsoft Graph para obter detalhes sobre registro de aplicativo e consentimento do administrador.

    graph-delta-sync.js
    // Sincronização delta do Microsoft Graph async function buscarMensagensDelta(cliente, deltaLink) { const url = deltaLink || '/me/messages/delta'; const res = await client .api(url) .selecionar('id,assunto,de,receivedDateTime') .obter(); return { mensagens: res.value, nextDelta: res['@odata.deltaLink'] }; }
    Logotipo IMAP IMAP - comando IDLE + UID FETCH Fallback universal para qualquer servidor de e-mail

    IMAP (RFC 3501) é anterior às APIs de sincronização modernas por décadas. Ele expõe por pasta números sequenciais e UIDs. Para sincronização delta, o CONDSTORE extensão (RFC 7162) adiciona uma MODSEQ valor para cada mensagem, permitindo que você recupere apenas mensagens com um MODSEQ maior que seu último valor conhecido via UID BUSCAR * (FLAGS) (CHANGEDSINCE modseq).

    Para push em tempo real, o IMAP suporta a IDLE comando (RFC 2177). Seu cliente envia IDLE e o servidor empurra EXISTE ou APAGAR respostas quando a pasta muda - sem necessidade de sondagem. A maioria dos servidores IMAP suporta IDLE; conexões devem ser atualizadas a cada 29 minutos para evitar timeouts.

    O IMAP é crucial porque abrange qualquer servidor de e-mail não gerenciado pelo Google ou Microsoft: Exchange corporativo (on-premise), ProtonMail, Zoho, Fastmail e domínios personalizados. Veja o Guia de integração IMAP para um tour completo de implementação.

    imap-idle-sync.js
    const Imap = require('imap'); const imap = new Imap({ host, porta: 993, tls: true }); imap.uma vez('pronto', () => { imap.openBox('Caixa de entrada', true, () => { imap.on('correio', (numNovos) => { // PUSH OCIOSO: novo e-mail chegou buscarNovasMensagens(numNovo); }); }); });
    Unipile - Cobertura de Recursos da API de E-mail
    Capacidades da API

    Cobertura de Recursos de API de E-mail por Provedor

    Uma única integração Unipile oferece acesso a todas as operações de e-mail em provedores Gmail, Outlook e IMAP. Clique em qualquer título de provedor para ler o guia de integração completo.

    Recurso Gmail Outlook / M365 IMAP / SMTP
    Autenticação
    OAuth2 (sem armazenamento de senha) Senha do aplicativo
    Fluxo de autenticação/consentimento hospedado
    Atualização automática de token
    Operações de E-mail
    Enviar e-mail da conta do usuário
    Ler e listar e-mails
    Enviar com anexos
    Responder na thread existente
    Gerenciamento de rascunhos
    Etiquetas / Pastas Rótulos Pastas Pastas
    Limite diário de envio (aprox.) ~500 por dia ~10.000 / dia Dependente de servidor
    Sincronização e Eventos
    Webhooks em tempo real
    Sincronização incremental de delta
    Agrupamento de threads
    SOC 2 Tipo II / CASA Nível 2
    Autenticação
    OAuth2 (sem armazenamento de senha)
    GmailGmail
    PerspectivasOutlook / M365
    IMAPIMAP / SMTP
    Senha do aplicativo
    Fluxo de autenticação/consentimento hospedado
    GmailGmail
    PerspectivasOutlook / M365
    IMAPIMAP / SMTP
    Atualização automática de token
    GmailGmail
    PerspectivasOutlook / M365
    IMAPIMAP / SMTP
    Operações de E-mail
    Enviar e-mail da conta do usuário
    GmailGmail
    PerspectivasOutlook / M365
    IMAPIMAP / SMTP
    Ler e listar e-mails
    GmailGmail
    PerspectivasOutlook / M365
    IMAPIMAP / SMTP
    Enviar com anexos
    GmailGmail
    PerspectivasOutlook / M365
    IMAPIMAP / SMTP
    Responder na thread existente
    GmailGmail
    PerspectivasOutlook / M365
    IMAPIMAP / SMTP
    Gerenciamento de rascunhos
    GmailGmail
    PerspectivasOutlook / M365
    IMAPIMAP / SMTP
    Etiquetas / Pastas
    GmailGmail
    Rótulos
    PerspectivasOutlook / M365
    Pastas
    IMAPIMAP / SMTP
    Pastas
    Limite diário de envio (aprox.)
    GmailGmail
    ~500 por dia
    PerspectivasOutlook / M365
    ~10.000 / dia
    IMAPIMAP / SMTP
    Dependente de servidor
    Sincronização e Eventos
    Webhooks em tempo real
    GmailGmail
    PerspectivasOutlook / M365
    IMAPIMAP / SMTP
    Sincronização incremental de delta
    GmailGmail
    PerspectivasOutlook / M365
    IMAPIMAP / SMTP
    Agrupamento de threads
    GmailGmail
    PerspectivasOutlook / M365
    IMAPIMAP / SMTP
    SOC 2 Tipo II / CASA Nível 2
    GmailGmail
    PerspectivasOutlook / M365
    IMAPIMAP / SMTP
    Experimente gratuitamente

    Pule o boilerplate do Gmail + Graph + IMAP. Uma API de sincronização de e-mail cobre os três.

    A API de sincronização de e-mail unificada da Unipile conecta-se ao Gmail, Outlook e IMAP através de um único endpoint. Fluxos OAuth, atualização de token, sincronização delta e webhooks - tudo gerenciado para você. Começa grátis, sem necessidade de cartão de crédito.

    Sem cartão de crédito
    Nível gratuito de API de e-mail disponível
    Operacional em 5 minutos
    Engenharia da Realidade

    A Complexidade Oculta da Sincronização de E-mails em Escala

    Construir uma API de sincronização de e-mail em prova de conceito leva um fim de semana. Construir uma que seja confiável em produção com 1.000 contas vinculadas leva meses. Eis o que ninguém lhe diz de antemão.

    Gerenciamento de limite de taxa

    O Gmail impõe cotas por usuário (250 unidades de cota/segundo) e limites diários por projeto. O Microsoft Graph implementa throttling a 10.000 requisições/10 minutos por aplicativo. Com 500 contas vinculadas sincronizando em horários programados, você precisa de um limitador de taxa distribuído com backoff exponencial, jitter e isolamento de fila por conta. Um único pico de uma conta pode esgotar a cota para todas as outras.

    Atualização de Token em Escala

    Cada conta vinculada tem um token de acesso que expira. Com 1.000 contas, você pode esperar dezenas de atualizações de tokens simultâneas durante as janelas de sincronização de pico. Uma única atualização falha pode levar a ciclos de sincronização perdidos. Você precisa de um serviço dedicado de ciclo de vida de token com lógica de retentativa, detecção de revogação e um pipeline de alerta para solicitar que os usuários reautorizem quando os tokens de atualização expirarem.

    Complexidade de Pasta e Etiqueta

    O Gmail usa marcadores (uma mensagem pode ter vários marcadores simultaneamente). O Outlook usa pastas (hierárquicas, com operações de mover). O IMAP também usa pastas, mas com espaços de nomes que variam de acordo com o fornecedor do servidor. Normalizar isso em um modelo de pasta consistente para seu aplicativo requer lógica de mapeamento específica do provedor. Casos extremos incluem caixas de correio compartilhadas, acesso delegado e a distinção do Gmail entre "Todos os e-mails" e "Caixa de entrada".

    Armazenamento e Transmissão de Anexos

    Anexos de e-mail podem ser grandes. Baixar e armazenar anexos para todos os e-mails sincronizados em milhares de contas aumenta rapidamente os custos de largura de banda e armazenamento. Você precisa de um pipeline de streaming que baixe anexos apenas sob demanda, armazenamento deduplicado e uma camada de CDN para servi-los a partir do seu produto. A análise MIME em si introduz bugs - e-mails multipartes, codificação quoted-printable e anexos inline exigem tratamento específico.

    Reconstrução de Tópico

    Threads do Gmail por threadId - um conceito do lado do servidor. O IMAP não tem encadeamento nativo; você reconstrói encadeamentos usando o Referências e Em-Resposta-A cabeçalhos (RFC 5322). O Outlook tem conversationId. A normalização de threads entre provedores - especialmente para respostas entre provedores - requer heurísticas de fallback baseadas na normalização de assuntos e cadeias de IDs de mensagem.

    Confiabilidade e Redelivery de Webhooks

    Notificações Pub/Sub do Gmail não são garantidas - mensagens perdidas durante o tempo de inatividade não são reenviadas. Assinaturas de webhook do Microsoft Graph expiram e precisam ser renovadas. Se o seu receptor de webhook estiver inativo durante uma notificação push, você perde o evento e recorre à consulta. Uma API de sincronização de e-mail de produção precisa de um loop de reconciliação que periodicamente recupera eventos perdidos usando o cursor de sincronização delta, independentemente da disponibilidade do webhook.

    Comparação de Arquitetura

    3 Arquiteturas de Sincronização de E-mail Comparadas

    Equipes que desenvolvem recursos de sincronização de e-mail geralmente avaliam três padrões de implementação. Aqui está uma comparação honesta de cada um, desde o esforço de desenvolvimento até o custo de manutenção contínua.

    Faça você mesmo
    Integração Direta com o Provedor
    API do Gmail + Microsoft Graph + IMAP - separadamente
    Tempo de compilação 3-6 meses
    Provedores cobertos 1 por sprint
    OAuth / gerenciamento de tokens código-fonte 3x
    Tratamento de Webhook 3 sistemas diferentes
    Manutenção contínua Alto (alterações na API)
    Modelo de custo Tempo de engenharia
    Auto-hospedado
    Camada IMAP Auto-Hospedada
    Execute seu próprio proxy de e-mail (Dovecot / Cyrus / custom)
    Tempo de compilação 2-4 meses
    Provedores cobertos Apenas IMAP (geral)
    OAuth / gerenciamento de tokens Credenciais IMAP apenas
    Tratamento de Webhook Baseado em IDLE, customizado
    Manutenção contínua Médio
    Modelo de custo Infra + engenharia
    Início rápido

    Sincronize E-mails com a API Unificada de Sincronização de E-mail da Unipile

    A API de sincronização de e-mail da Unipile cobre Gmail, Outlook e IMAP através de uma interface unificada. Fluxos OAuth, atualização de tokens, sincronização delta e entrega de webhooks são gerenciados para você - sua equipe implementa o recurso, não a infraestrutura.

    1
    Criar uma conta Unipile

    Cadastre-se em dashboard.unipile.com. O nível gratuito da API de e-mail oferece acesso a todos os provedores sem necessidade de cartão de crédito. Você obtém seu DSN (Nome da Fonte de Dados) e o token da API imediatamente.

    2
    Vincular a conta de e-mail de um usuário

    Use o fluxo de OAuth hospedado da Unipile para permitir que seu usuário autorize o acesso à sua conta Gmail ou Outlook. Para IMAP, colete suas credenciais e passe-as para POST /accounts. A Unipile lida com o redirecionamento OAuth, a troca de tokens e armazena o token de atualização de forma segura.

    3
    Listar e-mails sincronizados

    Chamar GET /emails com o account_id da conta vinculada. A Unipile executa a sincronização delta contra o Gmail histórico.listar, o endpoint delta do Microsoft Graph, ou IMAP CONDSTORE - você sempre obtém a mesma resposta JSON normalizada, independentemente do provedor.

    4
    Registre um webhook para sincronização em tempo real

    POSTe a URL do seu endpoint para a API de webhook da Unipile. Quando um novo e-mail chegar em qualquer conta vinculada - seja Gmail, Outlook ou IMAP - a Unipile entregará uma versão normalizada email.novo evento para sua URL. Nenhuma configuração do Pub/Sub, nenhuma renovação de assinatura do Graph, nenhum gerenciamento de conexão IDLE. Veja a guia da API de e-mail para referência completa do evento.

    5
    Ler todo o conteúdo do e-mail e anexos

    Chamar GET /emails/{id} para recuperar o corpo completo da mensagem (HTML e texto puro), cabeçalhos, partes MIME e referências de anexos. Os anexos são servidos via URLs assinadas - você nunca precisa armazenar dados MIME brutos. Veja ler e-mails programaticamente para exemplos.

    unipile-email-sync.js
    const áxis = require('axios'); const DSN = process.env.UNIPILE_DSN; const TOKEN = process.env.UNIPILE_TOKEN; const api = axios.create({ baseURL: https://${DSN}/api/v1, cabeçalhos: { 'X-API-KEY': TOKEN } }); // Passo 3 - Listar e-mails sincronizados async function listaremail(accountId) { const { dados } = await api.obter('/emails', { params: { account_id: account_id, pasta: 'Caixa de entrada', limite: 20 } }); return data.itens; } // Passo 4 - Registrar webhook async function registrarWebhook() { await api.postagem('/webhooks', { url: 'https://se Aap.com/api/email-events', eventos: ['email.novo', 'email.atualizado'] }); } // Passo 5 - Obter o conteúdo completo do e-mail async function obterEmail(emailId) { const { dados } = await api.obter(`/emails/${emailId}`); return dados; }
    Funciona com Gmail, Outlook e IMAP - mesmo código
    API de Sincronização de E-mail Unipile

    Chega de reconstruir o mesmo pipeline de sincronização de e-mail para cada provedor.

    Conecte Gmail, Outlook e IMAP através de uma única API de sincronização de e-mail. Webhooks em tempo real, sincronização delta e gerenciamento de tokens OAuth – tudo resolvido. Sua equipe foca no produto, não na infraestrutura.

    Comece gratuitamente Não é necessário cartão de crédito Ver nível gratuito da API de e-mail
    Unipile - Comparação de Sincronização de E-mail em Tempo Real
    Opções em Tempo Real

    Sincronização de E-mail em Tempo Real: Webhooks vs. Polling vs. IMAP IDLE

    Escolher o mecanismo de tempo real errado para sua API de sincronização de e-mail adiciona latência, consome quota ou deixa seu aplicativo cego durante interrupções. Aqui está uma comparação direta das três abordagens.

    Abordagem Como funciona Latência Melhor para Complexidade
    Webhooks (push) O provedor envia uma requisição HTTP POST para seu endpoint quando uma caixa de correio é alterada. O Gmail usa Pub/Sub; o Microsoft Graph usa notificações de alteração. Menos de 5 anos Gmail, Outlook, APIs unificadas como Unipile Médio gerenciamento de assinaturas necessário
    Pesquisa (agendada) Seu worker chama a API do provedor em um cronograma (a cada 30s, 1min, 5min) e busca alterações usando um cursor delta. 30s-5min Todos os provedores, configurações simples Baixa - mas intensivo em cota em escala
    IMAP IDLE (long-poll) Seu cliente envia IDLE para o servidor; o servidor envia notificações EXISTS quando novos e-mails chegam. Conexão mantida aberta por até 29 min. Menos de 1 ano Servidores IMAP apenas Alta - uma conexão TCP por caixa de correio
    Webhooks (push)
    Como funciona O provedor envia uma requisição HTTP POST para seu endpoint quando uma caixa de correio é alterada. O Gmail usa Pub/Sub; o Microsoft Graph usa notificações de alteração.
    Latência Menos de 5 anos
    Melhor para Gmail, Outlook, APIs unificadas como Unipile
    Complexidade Médiogerenciamento de assinatura necessário
    Pesquisa (agendada)
    Como funciona Seu worker chama a API do provedor em um cronograma (a cada 30s, 1min, 5min) e busca alterações usando um cursor delta.
    Latência 30s-5min
    Melhor para Todos os provedores, configurações simples
    Complexidade Baixamas com uso intensivo de cotas em escala
    IMAP IDLE (long-poll)
    Como funciona Seu cliente envia IDLE para o servidor; o servidor envia notificações EXISTS quando novos e-mails chegam. Conexão mantida aberta por até 29 min.
    Latência Menos de 1 ano
    Melhor para Servidores IMAP apenas
    Complexidade Altauma conexão TCP por caixa de correio

    Recomendação de produção: Use webhooks como seu mecanismo principal de tempo real e execute um fallback de polling delta-sync (a cada 5 minutos) para capturar eventos perdidos durante inatividade. Com a API de sincronização de e-mail da Unipile, ambos são configurados uma vez - o unificado email.novo o webhook é acionado independentemente de a conta ser Gmail, Outlook ou IMAP, e um loop de reconciliação em segundo plano lida automaticamente com eventos perdidos.

    Segurança e conformidade

    Segurança e Conformidade para APIs de Sincronização de E-mail

    Acessar as caixas de entrada dos usuários cria obrigações significativas de segurança e regulatórias. Veja o que sua implementação da API de sincronização de e-mail deve abordar antes de entrar em produção.

    Escopos OAuth - Princípio do Menor Privilégio

    Solicite apenas os escopos que seu aplicativo precisa. Para sincronização de e-mail somente leitura, solicite gmail.somente leitura em vez de gmail.modificar. Para o Microsoft Graph, solicitação Mail.Read em vez de Mail.ReadWrite. A verificação CASA do Google (obrigatória para aplicativos com mais de 100 usuários) analisa atentamente os escopos solicitados - escopos excessivos atrasam a aprovação.

    Armazenamento de Tokens - Criptografia em Repouso

    Tokens de atualização do OAuth são credenciais de longa duração que concedem acesso total à caixa de correio. Eles devem ser armazenados criptografados em repouso (AES-256 no mínimo) e nunca registrados. Rotacione as chaves de criptografia dos seus tokens periodicamente. O comprometimento de um token de atualização é equivalente ao comprometimento da senha da conta de e-mail conectada.

    LGPD e Residência de Dados

    O conteúdo de e-mails sincronizado de usuários da UE é considerado dado pessoal sob o GDPR. Você precisa de uma base legal para o processamento (tipicamente o consentimento explícito do usuário via OAuth), um acordo de processamento de dados com seu provedor de API de sincronização de e-mails e uma política clara de retenção de dados. Se sua infraestrutura for baseada nos EUA, garanta que você tenha SCCs (Cláusulas Contratuais Padrão) ou um mecanismo de transferência equivalente para dados da UE.

    Verificação Google CASA

    Qualquer aplicativo que utilize escopos OAuth do Gmail com mais de 100 usuários deve concluir os requisitos do Google. CASA (Avaliação de Segurança de Aplicações em Nuvem). Esta é uma revisão de segurança de seu aplicativo, incluindo código, infraestrutura e justificação do escopo do OAuth. O processo leva de 4 a 8 semanas. Comece cedo - falhar no CASA significa perder o acesso ao Gmail para todos os usuários até que você passe.

    Verificação de Assinatura de Webhook

    Sempre verifique a assinatura em cargas úteis de webhook recebidas da sua API de sincronização de e-mail. Um webhook não assinado ou verificado incorretamente pode ser falsificado para injetar eventos de e-mail falsos em seu aplicativo. O Unipile assina todas as entregas de webhook com HMAC-SHA256. Verifique a X-Unipile-Assinatura cabeçalho antes de processar qualquer evento.

    Registro de Auditoria

    Registre todas as ações que seu aplicativo executa em dados de e-mail sincronizados: quem acessou quais mensagens, quando e o que foi feito com os dados. Os logs de auditoria são necessários para a conformidade com o SOC 2 Tipo II e geralmente são a primeira coisa que clientes corporativos pedem durante revisões de segurança. Mantenha os logs por, no mínimo, 90 dias, idealmente por 1 ano.

    Erros Comuns

    Armadilhas Comuns ao Construir uma API de Sincronização de E-mail

    Estes são os erros e falhas de arquitetura que vemos com mais frequência em implementações de APIs de sincronização de e-mail. Todos eles são evitáveis com as escolhas de design corretas desde o início.

    1
    Não lidar com falhas de atualização de token de forma graciosa

    Quando um token de atualização expira ou é revogado, uma implementação ingênua lança um erro e para a sincronização - silenciosamente. O usuário não sabe que sua caixa de entrada parou de sincronizar até perceber dados desatualizados. Correção: implementar uma camada de detecção de revogação que captura concessão_inválida erros, marca a conta vinculada como necessitando de reautorização e notifica o usuário através do sistema de notificações do seu produto.

    2
    Pesquisando de forma muito agressiva e atingindo limites de taxa

    A consulta a cada 10 segundos em 200 contas vinculadas consome a cota por projeto do Gmail em poucas horas. O Microsoft Graph começa a retornar 429 Solicitações em excesso. O resultado são falhas de sincronização silenciosas para todas as contas - não apenas para aquelas que acionaram o limite. Correção: use webhooks as your primary mechanism with a 5-minute polling fallback, and implement per-account rate limiting with exponential backoff on all 429 respostas.

    3
    Armazenar o corpo MIME bruto em vez do conteúdo analisado

    O MIME bruto é grande, difícil de consultar e caro para analisar na leitura. Um único e-mail com anexos pode ter centenas de kilobytes. Correção: Analise o MIME na importação: extraia separadamente o corpo do HTML, o texto simples (como alternativa), os cabeçalhos e os metadados dos anexos. Armazene os arquivos binários dos anexos em um armazenamento de objetos (S3 ou equivalente), e não no seu banco de dados principal. Só isso já reduz os custos de armazenamento em 60% a 80% para caixas de correio corporativas típicas.

    4
    Falha na encadeamento de e-mails entre provedores

    Gmail threadId funciona apenas dentro do Gmail. Se o seu aplicativo mostrar um tópico que abrange uma conta do Gmail e uma conta do Outlook (por exemplo, uma resposta enviada de uma caixa de correio diferente), os IDs de encadeamento nativos são inúteis. Correção: construa um motor de threading multi-provedor com base no ID da Mensagem, Em-Resposta-Ae Referências cabeçalhos. Normalize linhas de assunto (remova prefixos Re:/Fwd:) como alternativa para e-mails que não possuem esses cabeçalhos.

    5
    Perder o cursor de sincronização ao reiniciar

    Delta sync depende de um cursor armazenado: o do Gmail. idHistórico, do Microsoft Graph deltaLink, IMAP MODSEQ. Se o seu worker de sincronização reiniciar e o cursor for armazenado apenas em memória, você perderá sua posição no fluxo de alterações. A próxima sincronização começará do zero, duplicando todas as mensagens históricas ou perdendo o intervalo. Correção: persista o cursor em seu banco de dados após cada ciclo de sincronização bem-sucedido, atomicamente com o último lote de alterações processadas.

    6
    Ignorando a distinção entre e-mails enviados e recebidos

    Para casos de uso de CRM, você precisa de e-mails de entrada (recebidos) e de saída (enviados) para construir uma linha do tempo completa da comunicação. O rótulo CAIXA de entrada do Gmail abrange apenas e-mails recebidos; você também precisa ENVIADO. O Microsoft Graph requer consulta ao Itens Enviados pasta separadamente. O IMAP exige a seleção da Enviado pasta explicitamente. Correção: sincronizar todas as pastas relevantes na configuração da conta, não apenas a CAIXA DE ENTRADA, e mapear nomes de pastas específicos do provedor para tipos normalizados em seu modelo de dados.

    PERGUNTAS FREQUENTES

    Perguntas Frequentes sobre APIs de Sincronização de Email

    As perguntas mais comuns que os desenvolvedores fazem ao implementar uma API de sincronização de e-mail pela primeira vez.

    1
    O que é uma API de sincronização de email?
    +
    Um API de sincronização de e-mail é uma interface programática que espelha continuamente a caixa de correio de um usuário em seu aplicativo. Ela lê mensagens de entrada e saída, rastreia alterações de status (lidas/não lidas, movimentações de pasta, exclusões) e entrega notificações em tempo real via webhooks quando novos e-mails chegam. Ao contrário de uma API de e-mail transacional (que envia e-mails do sistema), uma API de sincronização de e-mail requer que o usuário autorize o acesso à sua caixa de entrada existente via OAuth.
    2
    Qual é a diferença entre uma API de sincronização de e-mail e uma API de e-mail transacional?
    +
    Uma API de sincronização de e-mail lê e espelha a caixa de entrada de um usuário (Gmail, Outlook, IMAP) para seu aplicativo usando OAuth. Uma API de e-mail transacional (como SendGrid ou Mailgun) envia e-mails gerados pelo sistema de seu próprio domínio usando uma chave de API, sem acesso à caixa de entrada do usuário. Elas servem a propósitos opostos e segmentam mercados completamente diferentes. Unipile está na categoria de sincronização de e-mail - não é um remetente transacional.
    3
    Quais provedores de e-mail a API de sincronização de e-mail da Unipile suporta?
    +
    A API de sincronização de e-mail da Unipile suporta três provedores: Gmail (Google), Outlook / Microsoft 365 (Microsoft Graph - cobre tanto o Outlook pessoal quanto o M365 corporativo / Exchange Online), e IMAP (cobrindo qualquer servidor de e-mail, incluindo Exchange corporativo, ProtonMail, Zoho, Fastmail e domínios personalizados). Todos os três são acessíveis através do mesmo endpoint de API unificado.
    4
    Como funciona a sincronização delta em uma API de sincronização de e-mail?
    +
    Delta sync significa buscar apenas as alterações desde a última posição conhecida no fluxo de alterações da caixa de correio, em vez de buscar todas as mensagens em cada sondagem. O Gmail usa um idHistórico cursor com o usuários.histórico.lista endpoint. O Microsoft Graph usa um deltaLink de volta pelo /mensagens/delta endpoint. O IMAP usa o MODSEQ valor da extensão CONDSTORE. Uma API unificada de sincronização de e-mail normaliza esses três mecanismos diferentes por trás de uma interface consistente.
    5
    Qual é a diferença entre polling e webhooks para sincronização de e-mail?
    +
    Polling significa que seu worker chama a API de e-mail em um agendamento (a cada 30s, 1 minuto, etc.) para verificar novas mensagens. Webhooks são baseados em push: o provedor (ou API unificada) envia um POST HTTP para seu endpoint imediatamente quando um novo e-mail chega. Webhooks fornecem sincronização quase em tempo real (latência inferior a 5 segundos), enquanto polling introduz uma latência igual ao seu intervalo de polling. Em produção, o melhor padrão são webhooks como primários com um fallback de polling de sincronização delta para eventos perdidos.
    6
    Quanto tempo leva para configurar a sincronização de e-mail com o Unipile?
    +
    A maioria dos desenvolvedores tem um funcionando Sincronização de e-mail integração executada em um único dia. As etapas principais são: crie uma conta Unipile (gratuita, sem cartão de crédito), use o fluxo OAuth hospedado para permitir que um usuário conecte sua conta Gmail ou Outlook, chame GET /emails com o account_id para recuperar mensagens sincronizadas e registrar um endpoint de webhook para receber em tempo real email.novo eventos. Unipile lida com OAuth, atualização de tokens, sincronização delta e entrega de webhooks automaticamente.
    7
    Quais escopos OAuth eu preciso para sincronização de e-mail?
    +
    Para sincronização do Gmail somente leitura, solicitação gmail.somente leitura. Se precisar marcar mensagens como lidas ou movê-las, solicite gmail.modificar. Para o Microsoft Graph, solicitação Mail.Read para acesso somente leitura ou Mail.ReadWrite para acesso completo. Sempre solicite os escopos mínimos que seu aplicativo realmente precisa - a verificação CASA do Google (necessária para aplicativos com mais de 100 usuários) analisa de perto a justificativa do escopo, e escopagem excessiva pode atrasar sua aprovação.
    8
    Existe algum plano gratuito de API de sincronização de e-mail disponível?
    +
    Sim. A Unipile oferece uma API de e-mail gratuita que dá acesso aos três provedores (Gmail, Outlook, IMAP) sem a necessidade de cartão de crédito. O plano gratuito é adequado para desenvolvimento, testes e produção inicial com um pequeno número de contas vinculadas. Consulte a página de preços da Unipile ou a documentação da API de e-mail gratuita para os limites atuais.
    9
    Como lidar com tokens OAuth expirados em uma API de sincronização de e-mail?
    +
    Tokens de acesso expiram (tipicamente 1 hora para Google e Microsoft). Sua infraestrutura de sincronização deve detectar 401 Não autorizado respostas, use o token de atualização armazenado para obter um novo token de acesso e refaça a solicitação falha de forma transparente. Os próprios tokens de atualização podem ser revogados. Quando a revogação é detectada (concessão_inválida (erro), marque a conta como necessitando de reautorização e notifique o usuário. Unipile gerencia todo o ciclo de vida dos tokens automaticamente para contas vinculadas.
    10
    O que é IMAP IDLE e como ele permite a sincronização de e-mails em tempo real?
    +
    IMAP IDLE (RFC 2177) é um comando que coloca uma sessão IMAP em modo push: em vez de seu cliente fazer polling repetidamente, o servidor envia unsolicited EXISTE notificações quando novas mensagens chegam. Isso permite a sincronização quase em tempo real da caixa de entrada (latência inferior a 1 segundo) sem polling constante. As conexões IDLE devem ser atualizadas a cada 29 minutos para evitar timeouts do servidor. IDLE funciona com qualquer servidor IMAP que o suporte, o que inclui a maioria dos servidores de e-mail modernos, como o Exchange corporativo, Gmail via IMAP e Outlook via IMAP.
    pt_BRBR