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.
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']
});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.
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.
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.
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.
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.
Unipile NÃO está nesta categoria. Unipile é o lado de sincronização - leitura e espelhamento de caixas de entrada de usuários via OAuth.
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.
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-mailRastreie 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 programaticamenteAlimente 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 programaticamenteConverta 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-mailCapture 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-mailAnalise 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-mailComo 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.
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.
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.
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.
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.
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.
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.
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.
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', [])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.
// 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']
};
}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.
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);
});
});
});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 | ✓ | ✓ | ✓ |
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.
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.
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.
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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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;
}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.
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 |
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.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.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.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.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.