Dall'API REST di Outlook ed EWS a Microsoft Graph: la guida alla migrazione del 2026 per sviluppatori

Indice
Guida alla migrazione 2026

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.

graph-mail.js
// 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`);
GET /me/messages - 200 OK - 12 messaggi restituiti
Cos'è

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.

Chiarimento del nome
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 Unipile
Cronologia

Da 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.

2015 - 2017
Outlook REST API v2.0 Lancia

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.

2019
Microsoft Graph emerge come API unificata

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.

Novembre 2020
Annuncio di deprecazione per le API REST di Outlook v2.0

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".

2022 - 2023
Estensioni multiple della scadenza

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.

31 marzo 2024
API REST di Outlook v2.0 dismessa permanentemente

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.

1 ottobre 2026
Fine vita EWS per Exchange Online

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.

Unipile - Fine vita EWS
Scadenza critica

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.

Scadenza rigida EWS: 1° ottobre 2026 - Nessun periodo di tolleranza

Ambito: Solo Exchange Online (cloud Microsoft 365). I server Exchange locali non sono interessati. Applicazione Microsoft ha confermato che si tratta di un "hard cutover", ovvero le richieste EWS a Exchange Online cesseranno di essere elaborate. Cosa si rompe: tutte le chiamate SOAP/XML a outlook.office365.com/EWS/Exchange.asmx, inclusi app che utilizzano la libreria .NET di EWS Managed API, flussi di autenticazione Kerberos/NTLM e Basic Auth su EWS.

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 APIMicrosoft.Exchange.WebServices)
  • Notifiche in streaming tramite EWS
  • Impersonazione EWSImpersonazione 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 migrazione
Riferimento API

Endpoint 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
send-mail.js
// 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 correttamente

Punti 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 unificata
Autenticazione

Autenticazione 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.

Stato dell'autenticazione legacy (Maggio 2026): NTLM e Kerberos sono completamente disabilitati per Exchange Online. L'autenticazione di base è stata dismessa per Exchange Online nell'ottobre 2022. OAuth 2.0 tramite Azure AD è l'unico metodo di autenticazione accettato per Microsoft Graph.

Registrazione di un'app in Azure AD: 5 passaggi

01
Crea una registrazione di un'applicazione in Azure AD
Vai a 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.
02
Configura i permessi dell'API
Sotto 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.
03
Crea un segreto client (o certificato)
Sotto 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.
04
Implementare il flusso del codice di autorizzazione
Indirizza gli utenti a 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.
05
Richiedi il consenso dell'amministratore se necessario
Alcuni ambiti (come 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

Scorri orizzontalmente per vedere la tabella completa
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

JavaScript (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'
  })
});
Gestione del token di aggiornamento: I token di accesso di Microsoft Graph scadono dopo 1 ora. Memorizza il 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.
Piano d'azione

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.

Scadenza tassativa: 1° ottobre 2026. Nessuna estensione. Nessuna modalità di compatibilità. Pianifica subito la tua migrazione: un'applicazione EWS complessa può richiedere 4-8 settimane per essere migrata completamente su Microsoft Graph.
01
Revisiona il tuo attuale utilizzo di EWS
Inventaria ogni chiamata EWS nel tuo codebase: operazioni di posta, sincronizzazione del calendario, query sui contatti, notifiche push/pull/streaming. Questo determina l'ambito della tua migrazione e la stima dello sforzo.
02
Registra un'app di Azure AD e definisci gli ambiti
Crea la registrazione della tua app nel portale di Azure. Definisci gli ambiti minimi richiesti di Microsoft Graph per il tuo caso d'uso. Richiedi solo ciò di cui hai bisogno: evita permessi eccessivi.
03
Mappare le operazioni EWS sugli endpoint di Graph
Crea una tabella di traduzione: FindItem diventa GET /me/messages, CreateItem diventa POST /me/sendMail, FindAppointments diventa GET /me/events. Microsoft fornisce una guida ufficiale di mappatura EWS-Graph.
04
Sostituire WCF/SOAP con chiamate REST HTTP
EWS utilizza SOAP su HTTP. Microsoft Graph utilizza REST standard con JSON. Rimuovi tutte le classi proxy WCF, la serializzazione XML SOAP e le dipendenze dell'API gestita EWS dal tuo codebase.
05
Migrazione dell'autenticazione da protocolli legacy a OAuth 2.0
Sostituisci NTLM, Kerberos o Basic Auth con il flusso di autorizzazione OAuth 2.0 con codice di autorizzazione. Implementa la logica di refresh dei token utilizzando lo scope offline_access per mantenere accessi a lungo termine.
06
Test in tenant di sviluppo con Microsoft Graph Explorer
Utilizza Graph Explorer (developer.microsoft.com/graph/graph-explorer) per prototipare e testare le chiamate API prima di scrivere il codice. Imposta un tenant di sviluppo separato per evitare di testare su cassette postali di produzione.
07
Implementa le query delta per la sincronizzazione incrementale
Sostituire EWS SyncFolderItems con query delta di Graph (GET /me/messages/delta). Archiviare il token deltaLink per abilitare la sincronizzazione incrementale efficiente: verranno restituiti solo i cambiamenti dall'ultima query.
08
Gestione del limitazioni: HTTP 429 e Retry-After
Microsoft Graph applica rigidi limiti di frequenza. Implementa il backoff esponenziale: quando ricevi un HTTP 429, leggi l'header Retry-After e interrompi per esattamente quella durata prima di riprovare.
09
Aggiorna la gestione degli errori per il formato di errore di Graph
Gli errori del grafico utilizzano un formato diverso dalle eccezioni SOAP EWS. Analizza l'oggetto di errore JSON: { "error": { "code": "...", "message": "..." } }. Aggiorna di conseguenza tutta la gestione degli errori e il logging.
Scadenza
10
Avvio della produzione prima del 1° ottobre 2026
Pianifica il passaggio in produzione almeno 4 settimane prima della scadenza. Esegui EWS e Graph in parallelo durante un periodo di transizione per convalidare la correttezza prima di disattivare completamente il livello EWS.
Migra a Unipile e salta 8 di 10 passaggi - nessuna registrazione di app Azure, nessun flusso OAuth, nessuna logica di throttling da gestire.
Crea ora
Esempi di codice

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.

1 Leggi i messaggi in arrivo
EWS - TrovaElemento SOAP Deprecato
<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"/>
      
    
  
Microsoft Graph REST Attuale
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://..."
}
2 Inviare un'e-mail
EWS - CreaElemento SOAP Deprecato
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
Microsoft Graph REST Attuale
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)
3 Ottieni eventi del calendario
EWS - Trova Appuntamenti SOAP Deprecato
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"/>
  
Microsoft Graph REST Attuale
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
4 Iscriviti alle modifiche in tempo reale
EWS - Notifiche in Streaming Deprecato

  
    
      <t:DistinguishedFolderId
        Io="messaggi in arrivo"/>
    
    
      EventoNuovaEmail
      EventoEliminato
    
  
Iscriviti



Microsoft Graph Webhook Attuale
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.
Attenzione

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.

Permessi applicativi vs Permessi delegati
Questa è la confusione più comune. Delegato i permessi agiscono per conto di un utente connesso. Applicazione i permessi agiscono come un servizio senza contesto utente e richiedono il consenso dell'amministratore.
TipoContestoConsenso dell'amministratore
DelegatoUtente connessoA volte
ApplicazioneNessun utente / demoneSempre
Limiti di throttle: HTTP 429 e Retry-After
Microsoft Graph impone un limite di circa 10.000 richieste ogni 10 minuti per app per tenant. Quando viene limitato, ricevi 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.
Paginazione tramite @odata.nextLink
Graph impagina i risultati con una dimensione di pagina predefinita (tipicamente 10 messaggi). Se non si verifica @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.
Consenso dell'amministratore per gli ambiti sensibili
Ambiti come 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.
Stato della query Delta: gestione di deltaLink
Le query Delta restituiscono le modifiche dall'ultima sincronizzazione, identificate da un 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.
Gestione allegati: limite di dimensione di 3 MB
Gli allegati inferiori a 3 MB possono essere inclusi inline in un'unica chiamata API. Per file più grandi di 3 MB, devi prima creare una sessione di caricamento (POST /me/messages/{id}/attachments/createUploadSession) e caricare a blocchi. Tentare di incorporare un allegato di grandi dimensioni comporta 413 Richiesta troppo grande errore.
Approccio API unificato

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

Microsoft Graph - Leggi casella di posta (nativo) Circa 50 righe
// 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']) { /* ... */ }
Unipile - Leggi casella di posta (API unificata) 5 righe
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.
SOC 2 Tipo II
Conformità al GDPR
CASA Livello 2
SLA di disponibilità al 99,991% (TP3T)
Outlook + Gmail + IMAP
Smetti di ricostruire la stessa infrastruttura OAuth
Leggi email, invia messaggi, sincronizza calendari tra Outlook, Gmail e IMAP con una singola API. Unipile gestisce la complessità della migrazione da EWS a Graph in modo che il tuo team rilasci funzionalità invece di flussi di autenticazione.
Inizia a costruire con Unipile
Unipile - FAQ API REST di Outlook e EWS

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
it_ITIT
.