LinkedIn
Instagram
WhatsApp
Telegrama
Gmail
Perspectivas
Google Agenda
Participe da comunidade do SlackDe API REST do Outlook & EWS para o Microsoft Graph
A API REST do Outlook v2.0 foi descontinuada (março de 2024). O Exchange Web Services (EWS) chegará ao fim definitivo de sua vida útil em 1º de outubro de 2026. Este guia aborda todos os pontos de extremidade, fluxos OAuth e etapas de migração que você precisa implementar antes do prazo final.
Prazo final do EWS: 1º de outubro de 2026. A Microsoft confirmou que não haverá período de carência para o Exchange Online. Comece sua migração agora.
// API REST do Outlook via Microsoft Graph
// Substituir EWS SOAP por uma única chamada REST
const response = aguardar fetch(
'https://graph.microsoft.com/v1.0/me/messages',
{
cabeçalhos: {
'Authorization': `Bearer ${accessToken}`,
'Content-Type': 'application/json'
}
}
);
const { value: mensagens } = await resposta.json();
console.log(`Recuperados ${messages.length} e-mails`);Quais são as perspectivas para a API REST do Outlook em 2026?
O termo "Outlook REST API" gera confusão em 2026, pois a Microsoft o utilizou para descrever pelo menos três conceitos distintos ao longo da última década. Aqui está o significado exato atual, por que ele ainda é importante para os desenvolvedores e o que mudou.
Definição: Em 2026, "Outlook REST API" é um termo coloquial que se refere aos pontos de extremidade de e-mail do Microsoft Graph (https://graph.microsoft.com/v1.0/me/messages). A API REST dedicada original do Outlook v2.0 (outlook.office.com/api/v2.0) foi desativado definitivamente em 31 de março de 2024, retornando o código HTTP 410 Gone para todas as solicitações. O Microsoft Graph é agora a API única e unificada para e-mail, calendário e contatos no Microsoft 365, Exchange Online, Outlook.com e Teams.
Isso é importante em 2026 por duas razões: em primeiro lugar, qualquer aplicativo que ainda faça referência ao antigo outlook.office.com/api/ O domínio está com falha. Em segundo lugar, os aplicativos que utilizam o Exchange Web Services (EWS) — o protocolo mais antigo baseado em SOAP — enfrentam um prazo de conformidade obrigatório a partir de 1º de outubro de 2026 para o Exchange Online. Compreender a nomenclatura correta é o primeiro passo para uma migração bem-sucedida.
| Nome | Protocolo | URL base | Situação em 2026 |
|---|---|---|---|
| API REST do Outlook v2.0 | REST / JSON | outlook.office.com/api/v2.0 | Falecido (março de 2024) |
| Exchange Web Services (EWS) | SOAP / XML | outlook.office365.com/EWS/ | Fim da vida útil: outubro de 2026 |
| API do Microsoft Graph Mail | REST / JSON | graph.microsoft.com/v1.0/me/mensagens | Ao vivo - Use isto |
| MAPI / COM do Outlook | COM / Binário | Apenas para computador | Apenas para computador |
Para uma análise aprofundada da integração com o Microsoft Graph além do e-mail (webhooks, consultas delta, caixas de correio compartilhadas), consulte o Guia de integração de e-mail da API do Microsoft Graph. O guia de referência que abrange todos os padrões da API de e-mail está disponível em Guia do desenvolvedor da API de e-mail.
Planejando usar o Outlook em 2026? O Unipile oferece uma API de e-mail unificada que suporta o Microsoft Graph, o Gmail e o IMAP com uma única integração — sem necessidade de migração por provedor.
Construa com UnipileDo v2.0 ao Microsoft Graph: Uma Breve História
A descontinuação da API REST do Outlook v2.0 não foi repentina – a Microsoft a anunciou anos antes, com múltiplos adiamentos de prazo. Entender esse histórico ajuda você a antecipar o que a Microsoft fará com o EWS e por que o prazo de outubro de 2026 está sendo tratado como final.
A Microsoft introduz uma API baseada em REST em outlook.office.com/api/v2.0 como uma alternativa moderna ao EWS. Os desenvolvedores podem ler e-mails, gerenciar eventos de calendário e acessar contatos via JSON sobre HTTPS - uma melhoria significativa em relação ao SOAP/XML.
A Microsoft lança o Microsoft Graph como um único endpoint cobrindo todos os serviços do Microsoft 365 - e-mail, calendário, contatos, Teams, OneDrive, SharePoint e muito mais. O graph.microsoft.com o domínio se torna a maneira canônica de acessar dados da Microsoft programaticamente.
A Microsoft anuncia oficialmente a descontinuação da API REST do Outlook v2.0 (e v1.0 beta), citando o Microsoft Graph como substituto. O anúncio afirma explicitamente que os endpoints antigos deixarão de funcionar - com um prazo de "final de 2022" na época.
A Microsoft prorrogou o prazo duas vezes – primeiro para novembro de 2022, depois para março de 2023, e então para março de 2024. Cada prorrogação veio com um aviso: "esta é a última prorrogação". Muitos desenvolvedores interpretaram essas extensões como um sinal de que os prazos eram flexíveis. O prazo de outubro de 2026 para o EWS está sendo aplicado com mais rigor.
O outlook.office.com/api/v2.0 endpoint retorna HTTP 410 Gone para todas as solicitações. Chega de extensões. Qualquer aplicativo que ainda chame esses URLs está quebrado. "API REST do Outlook" agora significa Microsoft Graph quando usada corretamente. Para o guia de integração completo para endpoints de email do Microsoft Graph, consulte o Guia de integração de e-mail da API do Microsoft Graph.
O Exchange Web Services (EWS) irá parar de funcionar para o Exchange Online (nuvem Microsoft 365). A Microsoft confirmou que esta é uma data de aplicação rigorosa. Servidores Exchange on-premises não são afetados. Todos os aplicativos baseados em nuvem que usam chamadas EWS SOAP/XML devem ter migrado para o Microsoft Graph até esta data.
Por Que Esta Migração Foi Inevitável
Segurança Moderna do OAuth 2.0
As APIs mais antigas dependiam de autenticação básica e formatos de token legados. O Microsoft Graph exige OAuth 2.0 com o Azure Active Directory, alinhando-se com modelos de segurança de confiança zero e eliminando riscos de exposição de credenciais.
Plataforma Unificada de Identidade
O Microsoft Graph consolida o acesso a todos os serviços do Microsoft 365 através de uma única plataforma de identidade. Um registro de aplicativo, um token, um prefixo de ponto de extremidade - em vez de manter credenciais separadas por API legada.
Capacidades Mais Ricas
O Microsoft Graph expõe recursos que o EWS nunca teve: consultas delta para sincronização incremental, notificações de alteração (webhooks), busca em todo o conteúdo, integração com o Teams e análises específicas do Graph - tudo via REST/JSON limpo.
O Prazo Final Real de 2026: Fim de Vida do EWS (1º de outubro de 2026)
Embora a descontinuação da API REST do Outlook v2.0 tenha afetado um grupo relativamente pequeno de desenvolvedores, o fim da vida útil do EWS para o Exchange Online é um evento muito maior. Milhares de aplicativos corporativos, clientes de e-mail, ferramentas de sincronização de calendário e soluções de backup ainda dependem do Exchange Web Services. 1º de outubro de 2026 é a data limite definitiva - eis o que você precisa saber.
Quem é afetado
- Clientes de e-mail personalizados desenvolvidos com base na EWS Managed API
- Complementos do Outlook usando chamadas EWS (não baseados em Graph)
- Aplicativos de sincronização de calendário (reserva de salas, agendamento)
- Ferramentas de backup e arquivamento de e-mail
- Integrações de sincronização de e-mail de CRM / ATS
- Qualquer app usando
ExchangeService.Classe .NET
O que para de funcionar
- Autenticação NTLM e Kerberos
- Autenticação básica via EWS (já descontinuada)
- EWS Managed API (
Microsoft.Exchange.WebServices) - Notificações de streaming via EWS
- Impersonação do EWS
ExchangeImpersonation) - Operações SOAP: GetItem, FindItems, SyncFolderItems
O que NÃO é afetado
- Exchange 2016/2019 on-premises / SE EWS
- API do Microsoft Graph (este é o destino da migração)
- IMAP / SMTP para envio e recebimento básicos
- ActiveSync (descontinuado separadamente)
- aplicativo desktop do Outlook em si (usa MAPI proprietário)
A realidade do cronograma de migração
- Aplicativo simples com 1-2 operações EWS: 1-2 semanas
- Aplicativo de complexidade média (e-mail + agenda + contatos): 4 a 8 semanas
- Aplicativo corporativo com representação do EWS: 8 a 16 semanas
- Dependência de fornecedor (aguardando atualização da biblioteca): descontrolada
- Testes + UAT + implantação em produção: acrescentar 2 a 4 semanas
Está com um prazo apertado para a migração do EWS? A API de e-mail unificada da Unipile abstrai o Microsoft Graph (além do Gmail e do IMAP), permitindo que você faça a migração uma única vez e nunca mais precise lidar com código específico de cada provedor. Veja o Guia completo da API de e-mail para padrões de arquitetura.
Comece sua migraçãoPontos de extremidade da API REST do Outlook em 2026 (via Microsoft Graph)
Todas as funcionalidades da API REST do Outlook agora são disponibilizadas por meio do Microsoft Graph em https://graph.microsoft.com/v1.0. Abaixo estão os principais endpoints de e-mail, calendário e contatos, com seus métodos HTTP e um exemplo de código para cada categoria.
Pontos de acesso de e-mail
| Método | Ponto de extremidade | Descrição | Âmbito exigido |
|---|---|---|---|
| OBTER | /eu/mensagens |
Listar mensagens na caixa de entrada (compatível com $filter, $orderby, $top, $select) | Mail.Read |
| OBTER | /me/mensagens/{id} |
Obter uma única mensagem pelo ID, incluindo o corpo completo e os cabeçalhos | Mail.Read |
| POST | /me/enviarE-mail |
Enviar um novo e-mail imediatamente (sem salvar rascunho) | Mail.Send |
| POST | /eu/mensagens |
Criar um rascunho de mensagem (enviar separadamente via /enviar) | Mail.ReadWrite |
| PATCH | /me/mensagens/{id} |
Atualizar uma mensagem (marcar como lida, mover, alterar categorias) | Mail.ReadWrite |
| DELETE | /me/mensagens/{id} |
Excluir uma mensagem definitivamente | Mail.ReadWrite |
| OBTER | /me/pastas de e-mail |
Listar todas as pastas de e-mail (Caixa de entrada, Enviados, Rascunhos, personalizadas) | Mail.Read |
| OBTER | /eu/mensagens/delta |
Sincronização incremental - obter apenas mensagens alteradas desde a última sincronização | Mail.Read |
// POST /me/sendMail - Enviar por meio da API REST do Outlook (Microsoft Graph)
const response = await fetch('https://graph.microsoft.com/v1.0/me/enviarEmail', {
método: 'POST',
cabeçalhos: {
'Authorization': `Bearer ${accessToken}`,
'Content-Type': 'application/json'
},
corpo: JSON.stringify({
message: {
assunto: '"Olá, da Microsoft Graph"',
corpo: { contentType: 'Texto', conteúdo: '"Migração do EWS concluída!"' },
para os destinatários: [{ endereço de e-mail: { endereço: 'user@example.com' } }]
},
Salvar nos itens enviados: true
})
});
// 202 Aceito = enviado com sucessoPontos de extremidade do calendário
| Método | Ponto de extremidade | Descrição | Âmbito exigido |
|---|---|---|---|
| OBTER | /me/eventos |
Listar todos os eventos do calendário (suporta filtro $ por data de início/término) | Calendário.Ler |
| OBTER | /me/calendarView |
Obter eventos dentro de um intervalo de tempo (parâmetros startDateTime + endDateTime) | Calendário.Ler |
| POST | /me/eventos |
Criar um novo evento no calendário com participantes e recorrência | Calendários.LerGravar |
| OBTER | /me/calendários |
Listar todos os calendários do usuário (principal, compartilhado, de grupo) | Calendário.Ler |
Pontos de Contato
| Método | Ponto de extremidade | Descrição | Âmbito exigido |
|---|---|---|---|
| OBTER | /eu/contatos |
Listar todos os contatos na pasta de contatos padrão | Contatos.Leitura |
| POST | /eu/contatos |
Criar novo contato | Contatos.LerGravar |
| OBTER | /me/pastasDeContato |
Listar pastas de contatos | Contatos.Leitura |
Quer uma API única que lide com REST do Outlook (Microsoft Graph), Gmail e IMAP? Unipile une os três com um único endpoint unificado. Compare provedores em comparativo de provedores de API de email.
Construa com API UnificadaAutenticação OAuth 2.0: O Único Caminho a Seguir
A autenticação NTLM, Kerberos e Basic foram todas descontinuadas no Microsoft 365. O OAuth 2.0 é agora o método de autenticação obrigatório para todas as solicitações da API do Microsoft Graph. Não há alternativa, modo de compatibilidade nem prorrogação do prazo. Se sua aplicação ainda utiliza fluxos de autenticação legados, ela já está bloqueada para novos locatários e deixará de funcionar completamente para todos os locatários quando a aplicação do EWS for concluída em outubro de 2026.
Registro de aplicativos no Azure AD: 5 etapas
portal.azure.com - Azure Active Directory - Registros de aplicativo - Novo registro. Escolha um nome, defina o tipo de conta compatível (inquilino único, vários inquilinos ou contas pessoais) e configure um URI de redirecionamento.Permissões de API, adicione permissões do Microsoft Graph. Escolha entre permissões delegadas (contexto do usuário) ou de aplicativo (daemon), de acordo com o seu caso de uso. A maioria das integrações de e-mail/calendário utiliza permissões delegadas.Certificados e segredos, crie um novo segredo do cliente. Copie o valor imediatamente – ele só é mostrado uma vez. Para aplicativos em produção, um certificado é mais seguro do que um segredo do cliente.https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize com id_cliente, escopo, redirect_urie tipo_de_resposta=código. Após o consentimento, troque o código por tokens no endpoint de tokens.Mail.ReadWrite.All) exigem o consentimento do administrador do locatário antes que qualquer usuário possa autorizar. Para esses casos, use o endpoint de consentimento do administrador: /adminconsent fluxo com uma conta de administrador de locatário.Escopos OAuth Necessários para a Graph API
| Escopo | Tipo | Caso de uso |
|---|---|---|
| Mail.Read | Delegado | Ler as mensagens da caixa de correio do usuário |
| Mail.ReadWrite | Delegado | Ler e modificar mensagens da caixa de correio |
| Mail.Send | Delegado | Enviar e-mail em nome do usuário |
| Calendários.LerGravar | Delegado | Ler e modificar eventos do calendário |
| Contatos.Leitura | Delegado | Ler os contatos do usuário |
| Mail.ReadWrite.All | Aplicativo | Ler/gravar em todas as caixas de correio (aplicativos de serviço, requer consentimento do administrador) |
| Calendários.LerEscrever.Todos | Aplicativo | Ler/gravar em todos os calendários (aplicativos em segundo plano, requer permissão de administrador) |
| acesso_offline | Delegado | Necessário para receber um token de atualização para acesso de longa duração |
Fluxo do código de autorização - Exemplo em Node.js
// Passo 1: Construir URL de autorização
const authUrl = `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/authorize?`
+ new URLSearchParams({
client_id: ID_DO_CLIENTE,
response_type: 'código',
uri_de_redirecionamento: URI_DE_REDINICIONAMENTO,
escopo: 'Mail.Read Mail.Send Calendars.ReadWrite offline_access',
modo_resposta: 'consulta'
});
// Etapa 2: Trocar o código por tokens
const tokenRes = await fetch(
https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token,
{
method: 'POST',
corpo: new URLSearchParams({
client_id: ID_DO_CLIENTE,
client_secret: CHAVE_SECRETA_DO_CLIENTE,
código: authCode,
redirect_uri: URI_DE_REDINICIONAMENTO,
grant_type: ''código_de_autorização''
})
}
);
const { access_token, refresh_token } = await tokenRes.json();
// Passo 3: Atualizar quando o token de acesso expirar (geralmente 1 hora)
const refreshRes = await fetch(tokenEndpoint, {
method: 'POST',
body: new URLSearchParams({
client_id: ID_DO_CLIENTE,
client_secret: CHAVE_SECRETA_DO_CLIENTE,
refresh_token: token de atualização armazenado,
grant_type: 'token de atualização'
})
});token_de_atualização armazená-lo com segurança em seu banco de dados e usá-lo para solicitar novos tokens de acesso sem que o usuário precise se autenticar novamente. Os tokens de atualização podem expirar após 90 dias de inatividade. Sempre solicite o acesso_offline escopo para receber um token de atualização.
Lista de verificação para migração: do EWS para o Microsoft Graph em 10 etapas
A Microsoft confirmou que a descontinuação do EWS para o Exchange Online entrará em vigor a partir de 1º de outubro de 2026. Não haverá período de carência, opção de reversão nem ponte de compatibilidade. Todos os aplicativos que ainda utilizarem o Exchange Web Services para o Microsoft 365 deixarão de funcionar nessa data.
Exemplos de migração de código: EWS x Microsoft Graph
Abaixo, apresentamos uma comparação lado a lado de quatro operações comuns: a abordagem SOAP do EWS tradicional à esquerda e o equivalente REST do Microsoft Graph à direita. A mudança do XML prolixo para o JSON conciso fica imediatamente evidente.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
GET /me/messages
?$select=Assunto,De,receivedDateTime,bodyPreview
&$top=10
&$orderby=receivedDateTime decrescente
Autorização: Bearer {access_token}
// Resposta (JSON):
{
"valor": [
{
"identificador": "AAMkAGI...",
"assunto": "Olá",
"de": {
"endereço de e-mail": {
"endereço": "sender@example.com"
}
},
"dataHoraRecebimento": "27/05/2026"
}
],
"@odata.nextLink": "https://..."
}CriarItem Disposição da Mensagem="EnviarEGuardarCopia"
xmlns="http://schemas.microsoft.com/.../messagens">
Corpo da mensagem
POST /me/sendMail
Autorização: Bearer {access_token}
Content-Type: application/json
{
"mensagem": {
"assunto": "Olá de Graph",
"corpo": {
"tipoConteudo": "HTML",
"content" (conteúdo): "Corpo da mensagem
"
},
"paraDestinatários": [
{
"endereço de e-mail": {
"endereço": "to@example.com"
}
}
]
},
"salvarEmItensEnviados": true
}
// Resposta: HTTP 202 Accepted (sem corpo)<finditem</finditem Percurso=""Superficial"">
GET /me/eventos
?$select=assunto,início,fim,local,organizador
&$filter=data/hora de início ge '2026-05-01T00:00:00Z'
e fim/dataHora <= '2026-05-31T23:59:59Z'
&$top=50
&$orderby=início/dataHora asc
Autorização: Bearer {access_token}
// Retorna um array JSON limpo de
// objetos de evento de calendário - sem análise XMLPOST /assinaturas
Autorização: Bearer {access_token}
Content-Type: application/json
{
"tipo de alteração": "criado,atualizado,excluído",
"urlNotificacao": "https://seusite.com/webhook",
"recurso": "/me/mensagens",
"dataHoraValidade": "03/06/2026 18:00:00",
"estadoDoCliente": "seu-estado-secreto"
}
// O Gráfico envia POSTs para sua URL a cada alteração.
Renovar assinatura antes do vencimento.
// Nenhuma conexão persistente é necessária.Armadilhas comuns: permissões, limites de taxa, limitação de tráfego
Mesmo desenvolvedores experientes em Exchange Web Services frequentemente se deparam com os mesmos obstáculos ao migrar para o Microsoft Graph. Essas seis armadilhas são responsáveis pela maioria dos incidentes em produção durante a migração. Compreendê-las agora poupa dias de depuração mais tarde. Para uma visão mais ampla sobre como esses desafios se comparam entre os diferentes provedores, consulte nosso comparação de provedores de API de e-mail.
| Tipo | Contexto | Autorização do administrador |
|---|---|---|
| Delegado | Usuário conectado | Às vezes |
| Aplicativo | Sem usuário / daemon | Sempre |
HTTP 429 with a Tentar Novamente Após cabeçalho que especifica o tempo de espera em segundos. Ignorar esse cabeçalho e tentar novamente imediatamente resulta em um banimento prolongado. Sempre implemente o backoff exponencial com o valor exato de Retry-After.
@odata.nextLink Na resposta, você perde dados sem perceber. Sempre execute o loop: if @odata.nextLink está presente, faça outra requisição GET para essa URL (ela inclui o token de Pulo) até que o campo esteja ausente.
Mail.ReadWrite.All, Calendários.LerEscrever.Todose User.Read.All exigem que um administrador do locatário conceda consentimento antes que qualquer usuário possa autorizar seu aplicativo. Sem o consentimento do administrador, o fluxo OAuth retorna um AADSTS65001 erro. Use o /adminconsent ponto de extremidade durante a integração do aplicativo para clientes corporativos.
deltaLink token na página final. Armazene esse token de forma permanente — ele é o seu cursor de sincronização. Se você o perder, será necessário realizar uma ressincronização completa. Nunca defina um intervalo de tempo de forma rígida — use o deltaLink para evitar o processamento de duplicatas ou a perda de alterações.
POST /me/mensagens/{id}/anexos/criarSessãoDeUpload) e fazer o upload em partes. Tentar incorporar um anexo grande resulta em um 413 Entidade da solicitação muito grande erro.
Evite as dores de cabeça da migração: uma abordagem unificada com API de e-mail
Uma migração completa do EWS para o Graph em uma aplicação complexa leva de 4 a 8 semanas de trabalho de engenharia. É necessário registrar as aplicações do Azure, implementar fluxos OAuth, lidar com a atualização de tokens, gerenciar o controle de fluxo, reescrever todas as chamadas SOAP, atualizar o tratamento de erros e realizar testes em todos os ambientes. Depois, é preciso repetir tudo isso sempre que a Microsoft fizer alguma alteração.
O Unipile agrupa o Microsoft Graph, o Gmail e o IMAP em uma única API unificada. Basta autenticar seus usuários uma vez pelo Unipile para ler e enviar e-mails, sincronizar calendários e gerenciar contatos nos três provedores usando os mesmos pontos de extremidade — sem necessidade de registro de aplicativos no Azure, sem fluxos OAuth específicos para cada provedor e sem precisar manter uma lógica de limitação de tráfego. Veja nosso guia completo da API de e-mail e Comparação de provedores de API de e-mail para compreender o panorama.
50 linhas de código do Microsoft Graph contra 5 linhas de código do Unipile
// 1. Registro de aplicativo do Azure (portal.azure.com)
// 2. Fluxo de código de autorização OAuth
const authUrl = `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/authorize?`
+ new URLSearchParams({
client_id: CLIENT_ID,
response_type: 'código',
redirect_uri: REDIRECT_URI,
scope: 'Mail.Read offline_access',
modo_resposta: 'consulta'
});
// 3. Lida com o redirecionamento, troca o código por tokens
const tokenRes = await fetch(https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token, {
method: 'POST',
body: new URLSearchParams({
client_id: CLIENT_ID, client_secret: CLIENT_SECRET,
code: authCode, redirect_uri: REDIRECT_URI,
grant_type: ''código_de_autorização''
})
});
const { access_token, refresh_token } = await tokenRes.json();
// 4. Armazene os tokens de acesso e de atualização com expiração (a cada hora)
// 5. Gráfico de chamadas com token de portador
const res = await fetch('https://graph.microsoft.com/v1.0/me/messages?$top=10', {
headers: { Authorization: `Bearer ${access_token}` }
});
// 6. Gerenciar limitação de tráfego (HTTP 429 + Retry-After)
se (status_da_resolução === 429) {
const retryAfter = res.headers.obter(''Retry-After'');
await dormir(retryAfter * 1000);
// tentar novamente...
}
// 7. Paginar usando @odata.nextLink
const data = await res.json();
deixar mensagens = data.value;
enquanto (dado['@odata.nextLink']) { /* ... */ }// No aplicativo do Azure, nenhum fluxo OAuth para implementar,
// sem lógica de limitação, sem atualização de token.
// Funciona para Outlook E Gmail E IMAP.
const cliente = new UnipileClient(CHAVE_API);
const mensagens = await cliente.email.listarMensagens({
account_id: userAccountId, // conta vinculada
pasta: 'Caixa de entrada',
limit: 10
});
// Mesmo código, mesmo formato de resposta
// para Outlook, Gmail e IMAP.
// Unipile lida com Oauth, throttling,
// paginação e atualização de token.API REST e EWS do Outlook - Perguntas frequentes
Perguntas frequentes sobre a descontinuação da API REST do Outlook, a obsolescência do EWS e a migração para o Microsoft Graph
Não. A API REST do Outlook (v2.0 e beta) foi descontinuada pela Microsoft. Todas as solicitações enviadas aos pontos de extremidade REST legados do Outlook agora resultam em falha. O substituto oficial é Microsoft Graph, que cobre todas as mesmas operações de e-mail e calendário, além de muito mais. Se seu aplicativo ainda usa os pontos de extremidade REST do Outlook, a migração para o Grafo não é opcional.
A API REST do Outlook era uma API REST dedicada que abrangia apenas operações relacionadas à caixa de correio do Outlook. O Microsoft Graph é a API unificada para todo o ecossistema do Microsoft 365: e-mail do Outlook, calendário, contatos, Teams, SharePoint, OneDrive e muito mais. Ambas utilizam a autenticação OAuth 2.0, mas o Graph usa uma única URL base https://graph.microsoft.com/v1.0 e oferece uma interface mais consistente e rica em recursos do que os terminais específicos do Outlook, que foram descontinuados.
A Microsoft definiu 1 de outubro de 2026 como data definitiva para a descontinuação do EWS no Exchange Online (Microsoft 365). Após essa data, o EWS deixará de funcionar para as caixas de correio do Microsoft 365. Não há período de carência nem prorrogação anunciada. O EWS continuará funcionando para instalações locais do Exchange Server, que não são afetadas por esse prazo.
Microsoft Graph é o substituto oficial do EWS. Toda operação do EWS tem um equivalente no Graph: EncontrarItem se torna GET /me/messages, CriarItem enviar e-mail POST /me/sendMail, notificações de streaming se tornam webhooks do Graph via POST /assinaturas. Autenticação muda de NTLM/Kerberos/Basic Auth para OAuth 2.0 via Azure AD. Para equipes que precisam de um caminho mais simples, uma API de e-mail unificada como a Unipile resumo de todos os três provedores sob um único SDK.
Não. A API REST do Outlook v2.0 foi desativada. Solicitações para esses pontos de extremidade falharão com erros. O Microsoft Graph é o único caminho suportado para integração de e-mail e calendário do Outlook. Todas as novas integrações devem direcionar https://graph.microsoft.com/v1.0 e use a autenticação OAuth 2.0.
O esforço depende da complexidade da sua implementação do EWS. Uma integração simples com algumas operações de leitura/escrita geralmente leva de 1 a 2 semanas. Uma aplicação complexa com notificações de streaming, sincronização delta, operações de múltiplas pastas e tratamento extenso de erros pode levar de 4 a 8 semanas. A migração requer: registro de aplicativo do Azure AD, implementação do OAuth 2.0, substituição ponto a ponto, lógica de throttling, atualizações de paginação e alterações no formato de erro. Uma alternativa é utilizar A abstração do Microsoft Graph pela Unipile, que lida com a maior parte dessa complexidade automaticamente.
O prazo de outubro de 2026 aplica-se especificamente a Exchange Web Services (EWS) uso no Exchange Online. Os complementos do Outlook que utilizam a API Office.js seguem um cronograma distinto. No entanto, a Microsoft vem descontinuando gradualmente os complementos COM e VSTO legados em favor dos complementos do Office baseados na web. Se o seu complemento realizar chamadas EWS internamente, essas chamadas deixarão de funcionar em outubro de 2026, independentemente da estrutura do complemento. Consulte o roteiro do Microsoft 365 para obter as orientações mais recentes específicas para o seu tipo de complemento.
Como a API REST do Outlook foi descontinuada, os escopos relevantes são para Microsoft Graph. Escopos principais de e-mail: Mail.Read (ler mensagens), Mail.Send (enviar email), Mail.ReadWrite (ler e modificar mensagens), Calendários.LerGravar (acesso ao calendário), Contatos.Leitura (contatos). Sempre inclua acesso_offline para receber um token de atualização. Escopos em nível de aplicativo como Mail.ReadWrite.All requer consentimento do administrador do locatário e só deve ser usado em cenários de daemon sem contexto de usuário. Consulte nosso Guia OAuth do Microsoft Graph para um passo a passo completo de configuração.
O Microsoft Graph aplica limites de taxa de aproximadamente 10.000 solicitações por 10 minutos por aplicativo por locatário. Quando limitado, a API retorna HTTP 429 Muitos Pedidos with a Tentar Novamente Após cabeçalho que especifica o número exato de segundos a esperar. A regra fundamental: sempre respeite o Tentar Novamente Após exatamente esse valor. Tentar novamente antes que essa janela se feche prolonga o período de limitação. Em aplicações SaaS multilocatárias, nas quais cada locatário tem limites distintos, a limitação em um locatário não afeta os demais. Compare também IMAP como alternativa se a limitação de tráfego em grande escala for uma preocupação.
A Unipile é uma API de e-mail unificada que reúne o Microsoft Graph, o Gmail e o IMAP em um único SDK. Em vez de implementar fluxos OAuth do Microsoft Graph, gerenciar tokens de acesso, lidar com a limitação de tráfego e escrever código específico para cada provedor, você conecta as contas dos seus usuários por meio do Unipile e utiliza uma única API consistente para os três provedores. Isso é particularmente eficaz para aplicativos SaaS que precisam oferecer suporte simultâneo ao Outlook e ao Gmail sem a necessidade de manter código de integração separado para cada um. O Unipile opera como um intermediário técnico independente, agindo em nome de cada usuário autenticado, e não é afiliado nem endossado pela Microsoft.
Pule a migração do EWS inteiramente. Nossa equipe está aqui para ajudar.
Crie já
BR 
EN 
FR 
ES 
DE 
IT 
NL 
PL 
TR