Da API REST di Outlook EWS a Microsoft Graph
L'API REST di Outlook v2.0 è stata dismessa (marzo 2024). Exchange Web Services (EWS) raggiungerà il suo fine vita definitivo il 1° ottobre 2026. Questa guida copre ogni endpoint, flusso OAuth e passaggio di migrazione di cui avrai bisogno per completare le operazioni prima della scadenza.
EWS scadenza perentoria: 1 ottobre 2026. Microsoft ha confermato che non ci sarà alcun periodo di grazia per Exchange Online. Inizia subito la tua migrazione.
// API REST di Outlook tramite Microsoft Graph
// Sostituisci EWS SOAP con una singola chiamata REST
const response = attendere fetch(
'https://graph.microsoft.com/v1.0/me/messages',
{
intestazioni: {
'Authorization': Portatore ${accessToken}`,
'Content-Type': 'application/json'
}
}
);
const { value: messaggi } = await risposta.json();
console.log(`Ritrovate ${messages.length} e-mail`);Qual è la REST API di Outlook nel 2026?
Il termine "Outlook REST API" genera confusione nel 2026 perché Microsoft lo ha utilizzato per descrivere almeno tre cose distinte nel corso dell'ultimo decennio. Ecco il suo significato attuale preciso, perché è ancora importante per gli sviluppatori e cosa è cambiato.
Definizione: Nel 2026, "Outlook REST API" è un termine colloquiale che si riferisce ai punti di extremità di posta elettronica di Microsoft Graph (https://graph.microsoft.com/v1.0/me/messages). L'API REST originale dedicata di Outlook v2.0 (outlook.office.com/api/v2.0è stata dismessa permanentemente il 31 marzo 2024, restituendo HTTP 410 Gone per tutte le richieste. Microsoft Graph è ora l'unica API unificata per posta, calendario e contatti in Microsoft 365, Exchange Online, Outlook.com e Teams.
Questo è importante nel 2026 per due motivi: primo, qualsiasi applicazione che faccia ancora riferimento al vecchio outlook.office.com/api/ Il dominio è interrotto. In secondo luogo, le applicazioni che utilizzano Exchange Web Services (EWS), il vecchio protocollo basato su SOAP, devono rispettare una scadenza tassativa di applicazione fino al 1° ottobre 2026 per Exchange Online. Comprendere la corretta nomenclatura è il primo passo per una migrazione di successo.
| Nome | Protocollo | URL di base | Stato nel 2026 |
|---|---|---|---|
| Outlook API REST v2.0 | REST / JSON | outlook.office.com/api/v2.0 | Deceduto (mar 2024) |
| Exchange Web Services (EWS) | SOAP / XML | outlook.office365.com/EWS/ | Fine vita Ott 2026 |
| API Microsoft Graph Mail | REST / JSON | graph.microsoft.com/v1.0/me/messages | Dal vivo - Usa questo |
| MAPI / Outlook COM | COM / Binario | Solo desktop | Solo desktop |
Per un approfondimento sull'integrazione di Microsoft Graph oltre la posta (webhook, query delta, caselle di posta condivise), vedere Guida all'integrazione della posta elettronica con Microsoft Graph API. La guida dei pilastri che copre tutti i pattern delle API di posta elettronica si trova su Guida per sviluppatori API per email.
Costruire su Outlook nel 2026? Unipile ti offre un'API email unificata che gestisce Microsoft Graph, Gmail e IMAP con una singola integrazione - nessuna migrazione per provider necessaria.
Costruiscilo con UnipileDa v2.0 a Microsoft Graph: una breve storia
La deprecazione dell'API REST di Outlook v2.0 non è stata improvvisa: Microsoft l'ha annunciata con anni di anticipo, con molteplici proroghe delle scadenze. Comprendere questa cronologia ti aiuta ad anticipare cosa farà Microsoft con EWS e perché la scadenza di ottobre 2026 viene trattata come definitiva.
Microsoft introduce un'API basata su REST all'indirizzo outlook.office.com/api/v2.0 come alternativa moderna a EWS. Gli sviluppatori possono leggere le e-mail, gestire gli eventi del calendario e accedere ai contatti tramite JSON su HTTPS, un miglioramento significativo rispetto a SOAP/XML.
Microsoft lancia Microsoft Graph come endpoint unico che copre tutti i servizi di Microsoft 365: posta elettronica, calendario, contatti, Teams, OneDrive, SharePoint e altro ancora. La graph.microsoft.com il dominio diventa il modo canonico per accedere ai dati Microsoft a livello programmatico.
Microsoft annuncia ufficialmente l'obsolescenza dell'API REST di Outlook v2.0 (e v1.0 beta), citando Microsoft Graph come sostituto. L'annuncio afferma esplicitamente che i vecchi endpoint cesseranno di funzionare, con una scadenza prevista per la "fine del 2022".
Microsoft ha esteso la scadenza due volte, prima a novembre 2022, poi a marzo 2023 e infine a marzo 2024. Ogni estensione è stata accompagnata da un avvertimento: "questa è l'ultima estensione". Molti sviluppatori hanno interpretato queste estensioni come un segnale che le scadenze erano flessibili. La scadenza EWS di ottobre 2026 viene applicata in modo più rigoroso.
Il outlook.office.com/api/v2.0 l'endpoint restituisce HTTP 410 Gone per tutte le richieste. Non ci sono più estensioni. Qualsiasi applicazione che effettua ancora chiamate a questi URL è danneggiata. "Outlook REST API" ora significa Microsoft Graph quando viene utilizzato correttamente. Per la guida completa all'integrazione degli endpoint di posta elettronica di Microsoft Graph, vedere Guida all'integrazione della posta elettronica con Microsoft Graph API.
Exchange Web Services smetterà di funzionare per Exchange Online (Microsoft 365 cloud). Microsoft ha confermato che si tratta di una data di applicazione rigida. I server Exchange locali non sono interessati. Tutte le applicazioni basate su cloud che utilizzano chiamate SOAP/XML EWS devono essere migrate a Microsoft Graph entro tale data.
Perché questa migrazione era inevitabile
Sicurezza moderna di OAuth 2.0
Le API precedenti si basavano su Basic Auth e formati di token legacy. Microsoft Graph impone OAuth 2.0 con Azure Active Directory, allineandosi ai modelli di sicurezza zero-trust e eliminando i rischi di esposizione delle credenziali.
Piattaforma di Identità Unificata
Microsoft Graph consolida l'accesso a ogni servizio Microsoft 365 tramite un'unica piattaforma di identità. Una singola registrazione dell'app, un unico token, un unico prefisso endpoint, a fronte del mantenimento di credenziali separate per ogni API legacy.
Capacità più ricche
Microsoft Graph espone funzionalità che EWS non ha mai avuto: query delta per la sincronizzazione incrementale, notifiche di modifica (webhooks), ricerca su tutto il contenuto, integrazione con Teams e analisi specifiche per Graph, tutto tramite REST/JSON puliti.
La vera scadenza del 2026: End-of-Life di EWS (1° ottobre 2026)
Mentre la deprecazione dell'API REST di Outlook v2.0 ha interessato un gruppo relativamente piccolo di sviluppatori, la fine del supporto per EWS in Exchange Online è un evento di gran lunga più importante. Migliaia di applicazioni aziendali, client di posta elettronica, strumenti di sincronizzazione del calendario e soluzioni di backup si basano ancora su Exchange Web Services. Il 1° ottobre 2026 è la data di cutover definitiva: ecco cosa devi sapere.
Chi ne viene colpito
- Client di posta personalizzati basati su EWS Managed API
- Componenti aggiuntivi di Outlook che utilizzano chiamate EWS (non basate su Graph)
- Applicazioni di sincronizzazione del calendario (prenotazione sale, pianificazione)
- Strumenti di backup e archiviazione email
- Integrazioni di sincronizzazione e-mail CRM / ATS
- Qualsiasi app che utilizza
ExchangeService.Classe .NET
Cosa smette di funzionare
- Autenticazione NTLM e Kerberos
- Autenticazione di base su EWS (già deprecato)
- EWS Managed API
Microsoft.Exchange.WebServices) - Notifiche in streaming tramite EWS
- Impersonazione EWS
Impersonazione di Exchange) - Operazioni SOAP: GetItem, FindItems, SyncFolderItems
Cosa NON è influenzato
- Exchange 2016 / 2019 / SE On-premises EWS
- Microsoft Graph API (questo è l'obiettivo della migrazione)
- IMAP / SMTP per invio/ricezione di base
- ActiveSync (obsoleto separatamente)
- Applicazione desktop di Outlook stessa (utilizza MAPI proprietaria)
Cronologia della Migrazione: Realtà
- App semplice con 1-2 operazioni EWS: 1-2 settimane
- App di media complessità (posta elettronica + calendario + rubrica): 4-8 settimane
- App enterprise con impersonazione EWS: 8-16 settimane
- Dipendenza dal fornitore (in attesa di aggiornamento della libreria): incontrollata
- Test + UAT + rilascio in produzione: aggiungere 2-4 settimane
Sui tempi stretti per la migrazione EWS? L'API email unificata di Unipile astrae Microsoft Graph (e Gmail e IMAP) in modo da poter migrare una volta sola e non dover più toccare il codice specifico del provider. Vedi il Guida completa all'API per le email per pattern architetturali.
Inizia la tua migrazioneEndpoint REST di Outlook nel 2026 (tramite Microsoft Graph)
Tutte le funzionalità delle API REST di Outlook sono ora disponibili tramite Microsoft Graph su https://graph.microsoft.com/v1.0. Di seguito sono riportati gli endpoint principali per posta elettronica, calendario e contatti con i relativi metodi HTTP e un campione di codice per ciascuna categoria.
Punti di Accesso Email
| Metodo | Punto finale | Descrizione | Ambito richiesto |
|---|---|---|---|
| GET | /me/messaggi |
Elenca i messaggi nella posta in arrivo (supporta $filter, $orderby, $top, $select) | Posta.Leggi |
| GET | /io/messaggi/{id} |
Ottieni un singolo messaggio per ID con corpo completo e intestazioni | Posta.Leggi |
| POSTA | /io/inviaEmail |
Invia subito una nuova email (nessuna bozza salvata) | Mail.Send |
| POSTA | /me/messaggi |
Crea una bozza di messaggio (invia separatamente tramite /send) | Mail.ReadWrite |
| PATCH | /io/messaggi/{id} |
Aggiorna un messaggio (segna come letto, sposta, cambia categorie) | Mail.ReadWrite |
| CANCELLARE | /io/messaggi/{id} |
Elimina definitivamente un messaggio | Mail.ReadWrite |
| GET | /me/cartellePosta |
Elenca tutte le cartelle di posta (Posta in arrivo, Posta inviata, Bozze, personalizzate) | Posta.Leggi |
| GET | /me/messages/delta |
Sincronizzazione incrementale - ottieni solo i messaggi modificati dall'ultima sincronizzazione | Posta.Leggi |
// POST /me/sendMail - Invia tramite Outlook REST API (Microsoft Graph)
const response = await fetch('https://graph.microsoft.com/v1.0/me/inviaEmail', {
metodo: 'POST',
intestazioni: {
'Authorization': Portatore ${accessToken}`,
'Content-Type': 'application/json'
},
corpo: JSON.stringify({
message: {
soggetto: 'Ciao da Microsoft Graph',
corpo: { tipoContenuto: 'Testo', contenuto: 'Migrazione EWS completata!' },
aDestinatari: [{ indirizzoEmail: { indirizzo: 'user@example.com' } }]
},
salvaNellaPostaInviata: true
})
});
202 Accettato = inviato correttamentePunti finali del calendario
| Metodo | Punto finale | Descrizione | Ambito richiesto |
|---|---|---|---|
| GET | /me/eventi |
Elenca tutti gli eventi del calendario (supporta il filtro $ in base a data di inizio/fine) | Calendari.Lettura |
| GET | /io/vistaCalendario |
Ottieni eventi in un intervallo di tempo (parametri startDateTime + endDateTime) | Calendari.Lettura |
| POSTA | /me/eventi |
Crea un nuovo evento del calendario con partecipanti e ricorrenza | Calendari.LetturaScrittura |
| GET | /io/calendari |
Elenca tutti i calendari utente (principale, condiviso, di gruppo) | Calendari.Lettura |
Contatti Endpoint
| Metodo | Punto finale | Descrizione | Ambito richiesto |
|---|---|---|---|
| GET | /io/contatti |
Elenca tutti i contatti nella cartella contatti predefinita | Contatti.Lettura |
| POSTA | /io/contatti |
Crea un nuovo contatto | Contatti.LetturaScrittura |
| GET | /me/cartelleContatti |
Elenca cartelle di contatti | Contatti.Lettura |
Vuoi un'unica API che gestisca Outlook REST (Microsoft Graph), Gmail e IMAP? Unipile racchiude tutti e tre con un endpoint unificato. Confronta i provider su Confronto fornitori API email.
Costruisci con API unificataAutenticazione OAuth 2.0: L'Unica Strada da Percorrere
NTLM, Kerberos e autenticazione di base sono stati rimossi da Microsoft 365. OAuth 2.0 è ora il metodo di autenticazione obbligatorio per ogni richiesta di Microsoft Graph API. Non ci sono fallback, nessuna modalità di compatibilità e nessuna estensione della timeline. Se la tua applicazione utilizza ancora flussi di autenticazione legacy, è già bloccata per i nuovi tenant e smetterà completamente di funzionare per tutti i tenant quando l'applicazione delle policy EWS sarà completata nell'ottobre 2026.
Registrazione di un'app in Azure AD: 5 passaggi
portal.azure.com - Azure Active Directory - Registrazioni app - Nuova registrazione. Scegliere un nome, impostare il tipo di account supportato (tenant singolo, multitenant o account personali) e configurare un URI di reindirizzamento.Permessi API, aggiungere autorizzazioni Microsoft Graph. Scegliere Autorizzazioni delegate (contesto utente) o Autorizzazioni applicazione (demone) in base al proprio caso d'uso. La maggior parte delle integrazioni di posta elettronica/calendario utilizza autorizzazioni delegate.Certificati e segreti, crea un nuovo segreto client. Copia immediatamente il valore: verrà mostrato una sola volta. Per le app di produzione, un certificato è più sicuro di un segreto client.https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize con ID cliente, ambito, uri_di_reindirizzamento, e tipo_di_risposta=codice. Dopo aver ottenuto il consenso, scambia il codice per i token all'endpoint token.Mail.ReadWrite.All) richiedere il consenso dell'amministratore tenant prima che qualsiasi utente possa autorizzare. Per questi, utilizza l'endpoint di consenso dell'amministratore: /consensoadmin flusso con un account amministratore tenant.Scope OAuth Richiesti per l'API di Graph
| Ambito | Tipo | Caso d'uso |
|---|---|---|
| Posta.Leggi | Delegato | Leggi i messaggi della casella di posta dell'utente |
| Mail.ReadWrite | Delegato | Leggi e modifica messaggi della casella di posta |
| Mail.Send | Delegato | Inviare email per conto dell'utente |
| Calendari.LetturaScrittura | Delegato | Leggi e modifica eventi del calendario |
| Contatti.Lettura | Delegato | Leggi i contatti dell'utente |
| Mail.ReadWrite.All | Applicazione | Leggere/scrivere tutte le cassette postali (app daemon, richiede consenso dell'amministratore) |
| Calendars.ReadWrite.All | Applicazione | Leggi/scrivi tutti i calendari (app di sistema, richiede consenso amministratore) |
| accesso offline | Delegato | Richiesto per ricevere un token di aggiornamento per un accesso di lunga durata |
Flusso con codice di autorizzazione - Esempio Node.js
// Passo 1: Costruisci l'URL di autorizzazione
const authUrl = `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/authorize?`
+ new URLSearchParams({
client_id: ID_CLIENTE,
tipo_risposta: 'codice',
redirect_uri: URI_RED।RECT,
ambito: 'Mail.Read Mail.Send Calendars.ReadWrite offline_access',
modalità_risposta: 'richiesta'
});
// Passaggio 2: Scambia il codice per i token
const tokenRes = await fetch(
`https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token`,
{
method: 'POST',
corpo: new URLSearchParams({
client_id: ID_CLIENTE, segreto_client: SEGRETO_CLIENT,
codice: codice di autenticazione,
uri_di_reindirizzamento: URI_RED।RECT, tipo_concessione: 'codice_autorizzazione'
})
}
);
const { access_token, refresh_token } = await tokenRes.json();
// Passo 3: Aggiorna quando il token di accesso scade (tipicamente 1 ora)
const refreshRes = await fetch(tokenEndpoint, {
method: 'POST',
body: new URLSearchParams({
client_id: ID_CLIENTE,
client_secret: SEGRETO_CLIENT,
token_di_aggiornamento: refreshTokenArchiviato,
grant_type: 'token_di_aggiornamento'
})
});
token_di_aggiornamento nel tuo database in modo sicuro e usarlo per richiedere nuovi token di accesso senza richiedere all'utente di autenticarsi nuovamente. I token di aggiornamento possono scadere dopo 90 giorni di inattività. Richiedi sempre il accesso offline attribuire uno scope per ricevere un token di aggiornamento.
Checklist di migrazione: da EWS a Microsoft Graph in 10 passaggi
Microsoft ha confermato la dismissione definitiva di EWS per Exchange Online a partire dal 1° ottobre 2026. Non ci sarà alcun periodo di tolleranza, alcuna opzione di rollback e nessun ponte di compatibilità. Ogni applicazione che utilizzi ancora Exchange Web Services per Microsoft 365 smetterà di funzionare in quella data.
Esempi di migrazione codice: EWS vs Microsoft Graph
Di seguito vengono confrontate fianco a fianco 4 operazioni comuni: l'approccio legacy EWS SOAP sulla sinistra, l'equivalente Microsoft Graph REST sulla destra. Il passaggio da XML verboso a JSON pulito è immediatamente evidente.
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
TrovaOggetto Attraversamento="Superficiale"
xmlns="http://schemas.microsoft.com/exchange/services/2006/messages">
Predefinito
<IndexedPageItemView
MaxEntriesReturned="10"
Scostamento="0"
Punto base="Principio"/>
<t:DistinguishedFolderId Io="messaggi in arrivo"/>
Ottieni /me/messaggi
?$select=oggetto,da,dataOraRicezione,anteprimaCorpo
&$top=10
&$orderby=receivedDateTime decrescente
Autorizzazione: Bearer {access_token}
// Risposta (JSON):
{
"valore": [
{
"id": "AAMkAGI...",
"soggetto": "Ciao",
"da": {
"indirizzoElettronico": {
"indirizzo": "sender@example.com"
}
},
"dataOraRicezione": "27-05-2026T..."
}
],
"@odata.nextLink": "https://..."
}
Crea elemento Disposizione del messaggio="InviaECopia"
xmlns="http://schemas.microsoft.com/.../messaggi">
Ciao da EWS
<t:Corpo TipoDiCorpo="HTML">
Corpo del messaggio
to@example.com
CreaArticolo
POST /me/sendMail
Autorizzazione: Bearer {access_token}
Content-Type: application/json
{
"messaggio": {
"soggetto": "Ciao da Graph",
"corpo": {
"tipoContenuto": "HTML",
"contenuto": "Corpo del messaggio
"
},
"destinatari": [
{
"indirizzoElettronico": {
"indirizzo": "to@example.com"
}
}
]
},
"salvaInElementiInviati": true
}
// Risposta: HTTP 202 Accettato (nessun corpo)
TrovaOggetto Attraversamento="Superficiale">
TutteLeProprietà
VistaCalendario
MaxEntriesReturned="50"
Data di inizio="2026-05-01T00:00:00Z"
Data di fine="31-05-2026T23:59:59Z"
/>
<t:DistinguishedFolderId
Io="calendario"/>
GET /me/eventi
?$select=Oggetto,Inizio,Fine,Luogo,Organizzatore
&$filter=start/dateTime ge '2026-05-01T00:00:00Z'
e fine/dataOra '2026-05-31T23:59:59Z'
&$top=50
&$orderby=inizio/data_ora asc
Autorizzazione: Bearer {access_token}
// Restituisce un array JSON pulito di
// oggetti evento del calendario - nessuna analisi XML
<t:DistinguishedFolderId
Io="messaggi in arrivo"/>
EventoNuovaEmail
EventoEliminato
Iscriviti
POST /sottoscrizioni
Autorizzazione: Bearer {access_token}
Content-Type: application/json
{
"tipoDiCambio": "creato,aggiornato,eliminato",
"urlNotifica": "https://yourapp.com/webhook",
"risorsa": "/io/messaggi",
"dataOraScadenza": "03-06-2026 18:00:00",
"statoCliente": "il-tuo-segreto-stato"
}
Il grafo invia POST all'URL a ogni modifica.
Rinnova l'abbonamento prima della scadenza.
Nessuna connessione persistente richiesta.
Errori comuni: Permessi, Limiti di frequenza, Throttling
Anche gli sviluppatori esperti di Exchange Web Services si imbattono regolarmente negli stessi ostacoli quando migrano a Microsoft Graph. Queste 6 insidie rappresentano la maggior parte degli incidenti di produzione durante la migrazione. Comprenderle ora ti risparmia giorni di debug in seguito. Per una prospettiva più ampia su come queste sfide si confrontano tra i diversi provider, consulta la nostra confronto tra provider di API per email.
| Tipo | Contesto | Consenso dell'amministratore |
|---|---|---|
| Delegato | Utente connesso | A volte |
| Applicazione | Nessun utente / demone | Sempre |
HTTP 429 with a Ritenta dopo intestazione che specifica il tempo di attesa in secondi. Ignorare questa intestazione e riprovare immediatamente comporterà un ban prolungato. Implementare sempre un backoff esponenziale con il valore esatto di Retry-After.
@odata.nextLink Nella risposta, ometti silenziosamente dei dati. Esegue sempre un ciclo: se @odata.nextLink è presente, effettua un'altra richiesta GET a quell'URL (include il token di salto) finché il campo non è assente.
Mail.ReadWrite.All, Calendars.ReadWrite.All, e Utente.Leggi.Tutto richiedere a un amministratore tenant di concedere il consenso prima che qualsiasi utente possa autorizzare la tua app. Senza il consenso dell'amministratore, il flusso OAuth restituisce AADSTS65001 errore. Usa il /consensoadmin endpoint durante l'onboarding dell'app per i clienti aziendali.
deltaLink token nella pagina finale. Memorizza questo token in modo persistente: è il tuo cursore di sincronizzazione. Se lo perdi, dovrai eseguire una sincronizzazione completa. Non codificare mai in modo fisso un intervallo di tempo: utilizza il deltaLink per evitare di elaborare duplicati o modifiche mancanti.
POST /me/messages/{id}/attachments/createUploadSession) e caricare a blocchi. Tentare di incorporare un allegato di grandi dimensioni comporta 413 Richiesta troppo grande errore.
Salva il mal di testa della migrazione: approccio API unificato per le email
Una migrazione completa da EWS a Graph per un'applicazione complessa richiede da 4 a 8 settimane di tempo di ingegneria. È necessario registrare app Azure, implementare flussi OAuth, gestire il refresh dei token, gestire il throttling, riscrivere ogni chiamata SOAP, aggiornare la gestione degli errori e testare tra gli ambienti. Poi farlo di nuovo quando Microsoft cambia qualcosa.
Unipile astrae Microsoft Graph, Gmail e IMAP sotto un'unica API unificata. Autentichi i tuoi utenti una sola volta tramite Unipile e leggi/invia email, sincronizzi calendari e gestisci contatti attraverso tutti e tre i provider con gli stessi endpoint - nessuna registrazione di app Azure, nessun flusso OAuth per provider, nessuna logica di throttling da mantenere. Vedi il nostro Guida completa API email e confronto fornitori API email per capire il panorama.
50 righe di Microsoft Graph contro 5 righe di Unipile
// 1. Registrazione dell'app in Azure (portal.azure.com)
// 2. Flusso del codice di autorizzazione OAuth
const authUrl = `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/authorize?`
+ new URLSearchParams({
client_id: CLIENT_ID,
response_type: 'codice',
redirect_uri: REDIRECT_URI,
scope: 'Mail.Read offline_access',
modalità_di_risposta: 'richiesta'
});
// 3. Gestire il reindirizzamento, scambiare il codice con i token
const tokenResult = await fetch(`https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token`, ,
metodo: 'POST',
body: new URLSearchParams({
client_id: CLIENT_ID, client_secret: CLIENT_SECRET,
code: authCode, redirect_uri: REDIRECT_URI,
grant_type: 'codice_autorizzazione'
})
});
const { access_token, refresh_token } = await tokenRes.json();
// 4. Memorizzare i token di accesso e refresh alla scadenza (ogni ora)
// 5. Grafo delle chiamate con token Bearer
const ris = await fetch('https://graph.microsoft.com/v1.0/me/messages?$top=10', ,
headers: { Authorization: `Bearer ${access_token}` }
});
// 6. Gestire il throttling (HTTP 429 + Retry-After)
se (res.status === 429) {
const retryAfter = res.headers.ottenere('Riprovami dopo');
await dormire(retryAfter * 1000);
// riprovare...
}
// 7. Paginazione tramite @odata.nextLink
const dati = await res.json();
lascia messaggi = dati.valore;
mentre (dati['@odata.nextLink']) { /* ... */ }
Nessuna app Azure, nessun flusso OAuth da implementare,
// nessuna logica di limitazione, nessun refresh del token.
Funziona per Outlook, Gmail e IMAP.
const cliente = new UnipileClient(CHIAVE_API);
const messaggi = await client.email.elenca_messaggi({
account_id: userAccountId, // account collegato
cartella: 'POSTA IN ARRIVO',
limit: 10
});
// Stesso codice, stesso formato di risposta
// per Outlook, Gmail e IMAP.
// Unipile gestisce OAuth, throttling,
// paginazione e refresh dei token.
API REST di Outlook e EWS - FAQ
Domande frequenti sul ritiro dell'API REST di Outlook, la deprecazione di EWS e la migrazione a Microsoft Graph
No. L'API REST di Outlook (v2.0 e beta) è stata ritirata da Microsoft. Tutte le richieste agli endpoint REST legacy di Outlook ora falliscono. Il sostituto ufficiale è Microsoft Graph, che copre tutte le stesse operazioni di posta elettronica e calendario più molto altro. Se la tua applicazione utilizza ancora endpoint REST di Outlook, la migrazione a Graph non è facoltativa.
L'API REST di Outlook era un'API REST dedicata che copriva solo le operazioni della cassetta postale di Outlook. Microsoft Graph è l'API unificata per l'intero ecosistema Microsoft 365: posta, calendario, contatti, Teams, SharePoint, OneDrive e altro ancora di Outlook. Entrambe utilizzano l'autenticazione OAuth 2.0, ma Graph utilizza l'URL di base singolo https://graph.microsoft.com/v1.0 e offre un'interfaccia più coerente e ricca di funzionalità rispetto agli endpoint specifici di Outlook in disuso.
Microsoft ha impostato 1 ottobre 2026 come data di applicazione definitiva per la deprecazione di EWS in Exchange Online (Microsoft 365). Dopo questa data, EWS non funzionerà più per le cassette postali di Microsoft 365. Non ci sarà alcun periodo di tolleranza né proroghe annunciate. EWS continuerà a funzionare per le installazioni di Exchange Server on-premises, che non sono interessate da questa scadenza.
Microsoft Graph è il sostituto ufficiale di EWS. Ogni operazione di EWS ha un equivalente in Graph: TrovaOggetto diventa Ottieni /me/messaggi, CreaElemento (inviare email) diventa POST /me/sendMail, le notifiche di streaming diventano webhook di Graph tramite POST /sottoscrizioni. Autenticazione modificata da NTLM/Kerberos/Basic Auth a OAuth 2.0 tramite Azure AD. Per i team che necessitano di un percorso più semplice, un API email unificata come Unipile astrae tutti e tre i provider sotto un unico SDK.
No. L'API REST di Outlook v2.0 è ritirata. Le richieste a tali endpoint falliranno con errori. Microsoft Graph è l'unica via supportata per l'integrazione di posta elettronica e calendario di Outlook. Tutte le nuove integrazioni devono puntare a https://graph.microsoft.com/v1.0 e utilizza l'autenticazione OAuth 2.0.
Lo sforzo dipende dalla complessità dell'implementazione EWS. Una semplice integrazione con poche operazioni di lettura/scrittura richiede tipicamente 1-2 settimane. Un'applicazione complessa con notifiche in streaming, sincronizzazione delta, operazioni su più cartelle e gestione estesa degli errori può richiedere 4-8 settimane. La migrazione richiede: registrazione di un'app in Azure AD, implementazione di OAuth 2.0, sostituzione endpoint per endpoint, logica di throttling, aggiornamenti della paginazione e modifiche ai formati di errore. Un'alternativa è usare Astrazione di Microsoft Graph di Unipile, che gestisce automaticamente la maggior parte di questa complessità.
La scadenza di ottobre 2026 si applica specificamente a Exchange Web Services (EWS) utilizzo in Exchange Online. I componenti aggiuntivi di Outlook che utilizzano l'API Office.js seguono una tempistica separata. Tuttavia, Microsoft ha gradualmente eliminato i componenti aggiuntivi legacy COM e VSTO a favore dei componenti aggiuntivi Office basati sul Web. Se il tuo componente aggiuntivo effettua chiamate EWS internamente, tali chiamate verranno interrotte nell'ottobre 2026 indipendentemente dal framework del componente aggiuntivo. Controlla la roadmap di Microsoft 365 per le ultime indicazioni specifiche per il tuo tipo di componente aggiuntivo.
Poiché l'API REST di Outlook è stata ritirata, gli ambiti pertinenti sono per Microsoft Graph. Ambito dell'email principale: Posta.Leggi (leggi messaggi), Mail.Send (invia email), Mail.ReadWrite (leggi e modifica messaggi), Calendari.LetturaScrittura (accesso al calendario), Contatti.Lettura (contatti). Includi sempre accesso offline per ricevere un token di aggiornamento. Ambito a livello di applicazione come Mail.ReadWrite.All richiedere il consenso dell'amministratore tenant e deve essere utilizzato solo per scenari daemon senza contesto utente. Vedi il nostro Guida OAuth di Microsoft Graph per una guida completa alla configurazione.
Microsoft Graph applica limiti di frequenza di circa 10.000 richieste per 10 minuti per applicazione per tenant. Quando viene limitata, l'API restituisce 429 Troppe Richieste with a Ritenta dopo intestazione che specifica il numero esatto di secondi da attendere. La regola fondamentale: onora sempre il Ritenta dopo valore esatto. Riprovando prima che questa finestra si chiuda si estende il periodo di throttling. Per le applicazioni SaaS multi-tenant in cui ogni tenant ha limiti separati, il throttling su un tenant non influisce sugli altri. Confronta anche IMAP come alternativa se lo scale throttling è una preoccupazione.
Unipile è un API email unificata che incapsula Microsoft Graph, Gmail e IMAP sotto un unico SDK. Anziché implementare flussi OAuth di Microsoft Graph, gestire token di accesso, gestire il throttling e scrivere codice per provider specifici, si collegano gli account dei propri utenti tramite Unipile e si utilizza un'API coerente per tutti e tre i provider. Ciò è particolarmente efficace per le applicazioni SaaS che devono supportare contemporaneamente Outlook e Gmail senza mantenere codice di integrazione separato per ciascuno. Unipile opera come intermediario tecnico indipendente, agendo per conto di ciascun utente autenticato, e non è affiliato né approvato da Microsoft.
Saltare la migrazione EWS del tutto. Il nostro team è qui per aiutarvi.
Crea ora