LinkedIn
Instagram
WhatsApp
Telegramm
Google Mail
Ausblick
Google Kalender
Slack-Gemeinschaft beitretenVon Outlook REST API Und EWS zu Microsoft Graph
Die Outlook REST API v2.0 ist weg (März 2024). Exchange Web Services (EWS) erreicht sein endgültiges End-of-Life am 1. Oktober 2026. Diese Anleitung behandelt jeden Endpunkt, jeden OAuth-Flow und jeden Migrationsschritt, den Sie vor dem Stichtag umsetzen müssen.
EWS-Einsendeschluss: 1. Oktober 2026. Microsoft hat bestätigt, dass es keine Kulanzfrist für Exchange Online gibt. Beginnen Sie jetzt mit Ihrer Migration.
// Outlook REST API über Microsoft Graph
// Ersetzen Sie EWS SOAP durch einen einzigen REST-Aufruf
const response = await fetch(
'https://graph.microsoft.com/v1.0/me/messages',
{
Kopfzeilen: {
'Authorization': Träger ${accessToken},
'Content-Type': 'application/json'
}
}
);
const { value: Nachrichten } = await Antwort.json();
Konsole.log(`Es wurden ${messages.length} E-Mails abgerufen`);Was ist die Outlook REST-API im Jahr 2026?
Der Begriff "Outlook REST API" sorgt im Jahr 2026 für Verwirrung, da Microsoft ihn im letzten Jahrzehnt für mindestens drei unterschiedliche Dinge verwendet hat. Hier ist die genaue aktuelle Bedeutung, warum er für Entwickler immer noch wichtig ist und was sich geändert hat.
Definition: Im Jahr 2026 ist "Outlook REST API" ein umgangssprachlicher Begriff, der sich auf die E-Mail-Endpunkte von Microsoft Graph bezieht (https://graph.microsoft.com/v1.0/me/messages). Die ursprüngliche dedizierte Outlook REST-API v2.0 (outlook.office.com/api/v2.0wurde am 31. März 2024 endgültig stillgelegt und gibt für alle Anfragen den HTTP-Statuscode 410 Gone zurück. Microsoft Graph ist nun die einzige, einheitliche API für E-Mails, Kalender und Kontakte in Microsoft 365, Exchange Online, Outlook.com und Teams.
Das ist im Jahr 2026 aus zwei Gründen wichtig: Erstens, jede Anwendung, die noch auf die alte outlook.office.com/api/ Die Domain ist defekt. Zweitens stehen Anwendungen, die Exchange Web Services (EWS) verwenden – das ältere SOAP-basierte Protokoll –, bis zum 1. Oktober 2026 für Exchange Online unter einer strikten Durchsetzungsfrist. Das Verständnis der korrekten Nomenklatur ist der erste Schritt zu einer erfolgreichen Migration.
| Name | Protokoll | Basis-URL | Stand 2026 |
|---|---|---|---|
| Outlook REST API v2.0 | REST / JSON | outlook.office.com/api/v2.0 | Tot (März 2024) |
| Exchange Web Services (EWS) | SOAP / XML | outlook.office365.com/EWS/ | EoL Okt 2026 |
| Microsoft Graph Mail API | REST / JSON | graph.microsoft.com/v1.0/me/nachrichten | Live – Benutz es |
| MAPI / Outlook COM | COM / Binär | Nur für den Desktop | Nur für den Desktop |
Für einen tiefen Einblick in die Microsoft Graph-Integration über E-Mails hinaus (Webhooks, Delta-Abfragen, freigegebene Postfächer) siehe Microsoft Graph API E-Mail-Integrationsanleitung. Die Säulenanleitung, die alle E-Mail-API-Muster abdeckt, befindet sich unter E-Mail-API-Entwicklerhandbuch.
Bauen auf Outlook im Jahr 2026? Unipile bietet Ihnen eine einheitliche E-Mail-API, die Microsoft Graph, Gmail und IMAP mit einer einzigen Integration verarbeitet – keine migrationsbedingten Probleme pro Anbieter.
Bauen Sie es mit UnipileVon v2.0 zu Microsoft Graph: Eine kurze Geschichte
Die Abschaffung der Outlook REST API v2.0 erfolgte nicht plötzlich – Microsoft kündigte sie Jahre im Voraus an und gewährte mehrere Fristverlängerungen. Das Verständnis dieser Historie hilft Ihnen, vorauszusehen, was Microsoft mit EWS tun wird und warum die Frist im Oktober 2026 als endgültig betrachtet wird.
Microsoft führt eine REST-basierte API bei outlook.office.com/api/v2.0 Als moderne Alternative zu EWS können Entwickler E-Mails lesen, Kalendertermine verwalten und auf Kontakte über JSON über HTTPS zugreifen – eine deutliche Verbesserung gegenüber SOAP/XML.
Microsoft startet Microsoft Graph als zentralen Endpunkt, der alle Microsoft 365-Dienste abdeckt – E-Mail, Kalender, Kontakte, Teams, OneDrive, SharePoint und mehr. graph.microsoft.com Domänen werden zur kanonischen Art, über programmatischen Zugriff auf Microsoft-Daten zuzugreifen.
Microsoft gibt offiziell die Abschaffung der Outlook REST API v2.0 (und v1.0 Beta) bekannt und nennt Microsoft Graph als Ersatz. Die Ankündigung besagt ausdrücklich, dass die alten Endpunkte nicht mehr funktionieren werden – mit einer Frist von "Ende 2022" zu diesem Zeitpunkt.
Microsoft verlängert die Frist zweimal – zuerst bis November 2022, dann bis März 2023, dann bis März 2024. Jede Verlängerung ging mit der Warnung einher: "Dies ist die letzte Verlängerung." Viele Entwickler nahmen diese Verlängerungen als Signal, dass die Fristen flexibel seien. Die EWS-Frist im Oktober 2026 wird strenger durchgesetzt.
Die outlook.office.com/api/v2.0 Der Endpunkt gibt bei allen Anfragen den HTTP-Status 410 Gone zurück. Es gibt keine Erweiterungen mehr. Anwendungen, die diese URLs weiterhin aufrufen, funktionieren nicht mehr. "Outlook REST API" steht bei korrekter Verwendung nun für Microsoft Graph. Die vollständige Integrationsanleitung für die E-Mail-Endpunkte von Microsoft Graph finden Sie unter Microsoft Graph API E-Mail-Integrationsanleitung.
Exchange Web Services werden für Exchange Online (Microsoft 365 Cloud) den Dienst einstellen. Microsoft hat bestätigt, dass dies ein festes Durchsetzungsdatum ist. Lokale Exchange-Server sind nicht betroffen. Alle cloudbasierten Anwendungen, die SOAP/XML EWS-Aufrufe verwenden, müssen bis zu diesem Datum auf Microsoft Graph migriert worden sein.
Warum diese Migration unvermeidlich war
Moderne OAuth 2.0 Sicherheit
Die älteren APIs verließen sich auf Basic Auth und veraltete Tokenformate. Microsoft Graph schreibt OAuth 2.0 mit Azure Active Directory vor, das mit Zero-Trust-Sicherheitsmodellen übereinstimmt und Risiken bei der Offenlegung von Anmeldeinformationen eliminiert.
Einheitliche Identitätsplattform
Microsoft Graph bündelt den Zugriff auf alle Microsoft 365-Dienste über eine einzige Identitätsplattform. Eine App-Registrierung, ein Token, ein Endpunktpräfix – im Gegensatz zur Pflege separater Anmeldedaten für jede einzelne Legacy-API.
Umfangreichere Funktionen
Microsoft Graph bietet Funktionen, über die EWS nie verfügte: Delta-Abfragen für die inkrementelle Synchronisierung, Änderungsbenachrichtigungen (Webhooks), die Suche über alle Inhalte hinweg, die Teams-Integration sowie Graph-spezifische Analysen – alles über eine übersichtliche REST/JSON-Schnittstelle.
Die tatsächliche Frist für 2026: Ende der Lebensdauer von EWS (1. Oktober 2026)
Während die Einstellung der Outlook REST API v2.0 nur eine relativ kleine Gruppe von Entwicklern betraf, ist das Ende der Unterstützung für EWS in Exchange Online ein Ereignis von weitaus größerer Tragweite. Tausende von Unternehmensanwendungen, E-Mail-Clients, Kalendersynchronisierungstools und Backup-Lösungen sind nach wie vor auf Exchange Web Services angewiesen. Der 1. Oktober 2026 ist der endgültige Stichtag – hier erfahren Sie, was Sie wissen müssen.
Wer ist betroffen
- Benutzerdefinierte Mail-Clients, die auf der EWS Managed API basieren
- Outlook-Add-ins, die EWS-Aufrufe (nicht Graph-basiert) verwenden
- Kalendersynchronisierungsanwendungen (Raumbuchung, Terminplanung)
- E-Mail-Backup- und Archivierungs-Tools
- CRM / ATS E-Mail-Synchronisierungsintegrationen
- Jede App, die
Exchange-Dienst.NET-Klasse
Was funktioniert nicht
- NTLM- und Kerberos-Authentifizierung
- Basic Auth über EWS (bereits veraltet)
- EWS Managed API (
Microsoft.Exchange.WebServices) - Streaming-Benachrichtigungen über EWS
- EWS-Identitätsdiebstahl
ExchangeImpersonation) - SOAP-Operationen: GetItem, FindItems, SyncFolderItems
Was NICHT betroffen ist
- On-Premises Exchange 2016 / 2019 / SE EWS
- Microsoft Graph-API (dies ist das Migrationsziel)
- IMAP / SMTP für grundlegendes Senden/Empfangen
- ActiveSync (separat veraltet)
- Outlook-Desktopanwendung selbst (verwendet proprietäres MAPI)
Migrations-Zeitstrahl Realität
- Einfache App mit 1-2 EWS-Operationen: 1-2 Wochen
- Mittlere Komplexität App (E-Mail + Kalender + Kontakte): 4-8 Wochen
- Unternehmensanwendung mit EWS-Impersonation: 8-16 Wochen
- Anbieterabhängigkeit (Warten auf Bibliotheksupdate): unkontrolliert
- Tests + UAT + Produktionsbereitstellung: 2-4 Wochen zusätzlich
Sie haben nur wenig Zeit für die EWS-Migration? Die einheitliche E-Mail-API von Unipile abstrahiert Microsoft Graph (und Gmail und IMAP), sodass Sie nur einmal migrieren und nie wieder an anbieterspezifischen Code arbeiten müssen. Sehen Sie sich die Vollständiger E-Mail-API-Leitfaden für Architekturmuster.
Beginnen Sie Ihre MigrationOutlook REST API Endpunkte im Jahr 2026 (über Microsoft Graph)
Alle Outlook REST API-Funktionalitäten werden jetzt über Microsoft Graph unter bereitgestellt https://graph.microsoft.com/v1.0. Im Folgenden finden Sie die wichtigsten Endpunkte für E-Mails, Kalender und Kontakte mit ihren HTTP-Methoden und einem Codebeispiel für jede Kategorie.
Mail-Endpunkte
| Methode | Endpunkt | Beschreibung | Erforderlicher Umfang |
|---|---|---|---|
| GET | /ich/nachrichten |
Nachrichten im Posteingang auflisten (unterstützt $filter, $orderby, $top, $select) | Mail.Lesen |
| GET | /ich/nachrichten/{id} |
Einzelne Nachricht nach ID abrufen mit vollständigem Inhalt und Headern | Mail.Lesen |
| POST | /ich/E-Mail senden |
Senden Sie eine neue E-Mail sofort (kein Entwurf gespeichert) | Mail.Senden |
| POST | /ich/nachrichten |
Entwurf einer Nachricht (separat per /send senden) | Mail.ReadWrite |
| PATCH | /ich/nachrichten/{id} |
Nachricht aktualisieren (als gelesen markieren, verschieben, Kategorien ändern) | Mail.ReadWrite |
| DELETE | /ich/nachrichten/{id} |
Eine Nachricht dauerhaft löschen | Mail.ReadWrite |
| GET | /me/mailFolders |
Alle Mail-Ordner auflisten (Posteingang, Gesendet, Entwürfe, benutzerdefiniert) | Mail.Lesen |
| GET | /ich/nachrichten/delta |
Inkrementelle Synchronisierung – nur geänderte Nachrichten seit der letzten Synchronisierung abrufen | Mail.Lesen |
// POST /me/sendMail - Senden über die Outlook REST API (Microsoft Graph)
const response = await fetch('https://graph.microsoft.com/v1.0/me/sendMail', {
Methode: 'POST',
Kopfzeilen: {
'Authorization': Träger ${accessToken},
'Content-Type': 'application/json'
},
Körper: JSON.stringify({
message: {
Thema: 'Hallo von Microsoft Graph',
Körper: { Inhaltstyp: 'Text', Inhalt: 'EWS-Migration abgeschlossen!' },
AnEmpfänger: [{ E-Mail-Adresse: { Adresse: 'user@example.com' } }]
},
inGesendeteObjekteSpeichern: true
})
});
202 Akzeptiert = erfolgreich gesendetKalender-Endpunkte
| Methode | Endpunkt | Beschreibung | Erforderlicher Umfang |
|---|---|---|---|
| GET | /ich/ereignisse |
Alle Kalendertermine auflisten (unterstützt $-Filter nach Start-/Endzeit) | Kalender.Lesen |
| GET | /ich/Kalenderansicht |
Ereignisse in einem Zeitbereich abrufen (Parameter startDateTime + endDateTime) | Kalender.Lesen |
| POST | /ich/ereignisse |
Neuen Kalendertermin mit Teilnehmern und Wiederholung erstellen | Kalender.LesenSchreiben |
| GET | /me/kalender |
Alle Nutzerkalender auflisten (primär, geteilt, Gruppen) | Kalender.Lesen |
Kontaktenpunkte
| Methode | Endpunkt | Beschreibung | Erforderlicher Umfang |
|---|---|---|---|
| GET | /ich/kontakte |
Alle Kontakte im Standard-Kontaktordner auflisten | Kontakte.Lesen |
| POST | /ich/kontakte |
Neuen Kontakt erstellen | Kontakte.LesenSchreiben |
| GET | /me/Kontaktordner |
Kontaktordner auflisten | Kontakte.Lesen |
Willst du eine einzige API, die Outlook REST (Microsoft Graph), Gmail und IMAP verarbeitet? Unipile fasst alle drei mit einem einzigen, einheitlichen Endpunkt zusammen. Vergleichen Sie Anbieter unter Vergleich von E-Mail-API-Anbietern.
Mit der einheitlichen API entwickelnOAuth 2.0-Authentifizierung: Der einzig gangbare Weg
NTLM, Kerberos und Basic Authentication sind für Microsoft 365 nicht mehr verfügbar. OAuth 2.0 ist nun die obligatorische Authentifizierungsmethode für jede Microsoft Graph API-Anfrage. Es gibt keine Rückfalloption, keinen Kompatibilitätsmodus und keine Verlängerung des Zeitplans. Wenn Ihre Anwendung noch Legacy-Authentifizierungsflüsse verwendet, ist sie für neue Mandanten bereits gesperrt und wird für alle Mandanten vollständig unterbrochen, wenn die EWS-Durchsetzung im Oktober 2026 abgeschlossen ist.
Azure AD App-Registrierung: 5 Schritte
portal.azure.com - Azure Active Directory - App-Registrierungen - Neue Registrierung. Wählen Sie einen Namen, legen Sie den unterstützten Kontotyp (Einzelmandant, Mehrfachmandant oder persönliche Konten) fest und konfigurieren Sie eine Weiterleitungs-URI.API-Berechtigungen, füge Microsoft Graph-Berechtigungen hinzu. Wähle Delegierte (Benutzerkontext) oder Anwendungs- (Daemon) Berechtigungen je nach Anwendungsfall. Die meisten E-Mail-/Kalenderintegrationen verwenden Delegierte Berechtigungen.Zertifikate & Geheimnisse, erstellen Sie ein neues Clients-Geheimnis. Kopieren Sie den Wert sofort – er wird nur einmal angezeigt. Für Produktions-Apps ist ein Zertifikat sicherer als ein Clients-Geheimnis.https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize mit client_id, Umfang, redirect_uriund Antworttyp=Code. Nach der Zustimmung tauschen Sie den Code am Token-Endpunkt gegen Token aus.Mail.ReadWrite.All) die Zustimmung des Mandantenadministrators erfordern, bevor ein Benutzer autorisieren kann. Verwenden Sie für diese den Endpunkt für die Administratorenzustimmung: /adminzustimmung mit einem Tenant-Administrator-Konto arbeiten.Erforderliche OAuth-Bereiche (Scopes) für die Graph-API
| Umfang | Typ | Anwendungsfall |
|---|---|---|
| Mail.Lesen | Delegiert | Benutzermeldungen im Postfach lesen |
| Mail.ReadWrite | Delegiert | Postfächer lesen und bearbeiten |
| Mail.Senden | Delegiert | E-Mail im Namen des Benutzers senden |
| Kalender.LesenSchreiben | Delegiert | Kalenderereignisse lesen und ändern |
| Kontakte.Lesen | Delegiert | Benutzerkontakte lesen |
| Mail.ReadWrite.All | Anmeldung | Alle Mailboxen lesen/schreiben (Daemon-Apps, erfordert Admin-Zustimmung) |
| Kalender.LesenSchreiben.Alle | Anmeldung | Auf alle Kalender zugreifen (Daemon-Apps, erfordert die Zustimmung des Administrators) |
| Offline-Zugriff | Delegiert | Erforderlich zum Empfang eines Aktualisierungstokens für langlebigen Zugriff |
Autorisierungscode-Fluss - Node.js Beispiel
// Schritt 1: Autorisierungs-URL erstellen
const authUrl = `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/authorize?`
+ new URLSearchParamsclient_id: CLIENT_ID,
response_type: 'Code',
redirect_uri: UMLEITUNGS_URI,
Geltungsbereich: 'Mail.Read Mail.Send Calendars.ReadWrite offline_access',
antwortmodus: 'Anfrage'
});
// Schritt 2: Code gegen Token austauschen
const tokenRes = await fetch(
`https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token`,
{
Methode: 'POST',
körper: new URLSearchParamsclient_id: CLIENT_ID,
client_geheimnis: CLIENT_SECRET,
code: Autorisierungscode,
redirect_uri: UMLEITUNGS_URI,
grant_type: 'autorisierungscode'
})
}
);
const { access_token, refresh_token } = await tokenRes.json();
// Schritt 3: Aktualisieren, wenn das Zugriffstoken abläuft (typischerweise 1 Stunde)
const refreshRes = await fetchtokenEndpoint, {
Methode: 'POST',
body: new URLSearchParamsclient_id: CLIENT_ID,
client_secret: CLIENT_SECRET,
aktualisierungs_token: gespeicherter_aktualisierungstoken,
grant_type: 'Aktualisierungstoken'
})
});Aktualisierungsschlüssel sicher in Ihrer Datenbank gespeichert und zur Anforderung neuer Zugriffstoken verwendet werden, ohne dass der Benutzer sich erneut authentifizieren muss. Refresh-Token können nach 90 Tagen Inaktivität ablaufen. Fordern Sie immer die Offline-Zugriff Berechtigung zum Erhalt eines Aktualisierungstokens.
Migrations-Checkliste: Von EWS zu Microsoft Graph in 10 Schritten
Microsoft hat die strikte Durchsetzung der Stilllegung von EWS für Exchange Online zum 1. Oktober 2026 bestätigt. Es gibt keine Kulanzzeit, keine Rückfalloption und keine Kompatibilitätsbrücke. Jede Anwendung, die noch Exchange Web Services für Microsoft 365 nutzt, wird an diesem Datum ausfallen.
Code-Migrationsbeispiele: EWS vs. Microsoft Graph
Im Folgenden werden 4 gängige Operationen nebeneinander verglichen: der alte EWS SOAP-Ansatz auf der linken Seite, das Microsoft Graph REST-Äquivalent auf der rechten Seite. Der Übergang von ausführlichem XML zu übersichtlichem JSON ist sofort ersichtlich.
<soap:Umschlag xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
GET /me/messages
?$select=Betreff,Von,Empfangsdatum und -uhrzeit,Vorschau des Textes
&$top=10
&$orderby=receivedDateTime absteigend
Autorisierung: Bearer {access_token}
// Antwort (JSON):
{
"Wert": [
{
"id": "AAMkAGI...",
"Betreff": "Hallo",
"von": {
"E-Mail-Adresse": {
"Adresse": "sender@example.com"
}
},
"Empfangsdatum-Zeit": ""27.05.2026 um ...""
}
],
"@odata.nextLink": "https://..."
}<EintragErstellen Nachrichtenverteilung="SendenUndKopieSpeichern"
xmlns="http://schemas.microsoft.com/.../messages">
Nachrichteninhalt
POST /me/sendMail
Autorisierung: Bearer {access_token}
Inhaltstyp: Anwendung/JSON
{
"Nachricht": {
"Betreff": "Hallo von Graph",
"Körper": {
"Inhaltstyp": "HTML",
"Inhalt": "Nachrichteninhalt
"
},
"anEmpfänger": [
{
"E-Mail-Adresse": {
"Adresse": "to@example.com"
}
}
]
},
"in gesendete Elemente speichern": true
}
// Antwort: HTTP 202 Accepted (kein Hauptteil)Gegenstand finden Durchlaufen="Oberflächlich">
GET /me/events
?$select=Thema,Beginn,Ende,Ort,Organisator
&$filter=start/dateTime ge '2026-05-01T00:00:00Z'
und ende/zeitStempel le '2026-05-31T23:59:59Z'
&$top=50
&$orderby=start/datum asc
Autorisierung: Bearer {access_token}
// Gibt ein sauberes JSON-Array von zurück
// Kalenderereignisobjekte - keine XML-VerarbeitungPOST /abonnements
Autorisierung: Bearer {access_token}
Inhaltstyp: Anwendung/JSON
{
"Änderungstyp": "erstellt,aktualisiert,gelöscht",
"notificationUrl": "https://yourapp.com/webhook",
"Ressource": "/ich/nachrichten",
"AblaufdatumUhrzeit": "2026-06-03T18:00:00Z",
"clientZustand": "dein-geheimer-zustand"
}
// Graph POSTet bei jeder Änderung an Ihre URL.
Abonnement vor Ablauf verlängern.
Keine persistente Verbindung erforderlich.Häufige Fallstricke: Berechtigungen, Ratenlimits, Drosselung
Selbst Entwickler, die mit Exchange Web Services vertraut sind, stoßen bei der Migration zu Microsoft Graph regelmäßig auf dieselben Hürden. Diese 6 Fallstricke sind für die Mehrheit der Produktionsausfälle während der Migration verantwortlich. Wenn Sie diese jetzt verstehen, sparen Sie später Tage beim Debugging. Für eine breitere Perspektive darauf, wie diese Herausforderungen im Vergleich zu anderen Anbietern aussehen, siehe unser Vergleich von E-Mail-API-Anbietern.
| Typ | Kontext | Admin-Zustimmung |
|---|---|---|
| Delegiert | Benutzer angemeldet | Manchmal |
| Anmeldung | Kein Benutzer / Daemon | Immer |
HTTP 429 with a Erneut versuchen nach Header, der die Wartezeit in Sekunden angibt. Wenn dieser Header ignoriert und sofort erneut versucht wird, führt dies zu einem erweiterten Bann. Implementieren Sie immer exponentielles Backoff mit dem genauen Retry-After-Wert.
@odata.nextLink in der Antwort fehlen Ihnen stillschweigend Daten. Schleifen Sie immer: wenn @odata.nextLink ist vorhanden, machen Sie einen weiteren GET-Request an diese URL (sie enthält den Skip-Token), bis das Feld nicht mehr vorhanden ist.
Mail.ReadWrite.All, Kalender.LesenSchreiben.Alleund Benutzer.AlleLesen Einen Mandantenadministrator erforderlich, der die Zustimmung erteilt, bevor ein Benutzer Ihre App autorisieren kann. Ohne Zusage des Administrators gibt der OAuth-Fluss Folgendes zurück: AADSTS65001 Fehler. Benutze die /adminzustimmung Endpunkt während des App-Onboardings für Unternehmenskunden.
DeltaLink Token auf der letzten Seite. Speichern Sie dieses Token persistent – es ist Ihr Synchronisationscursor. Wenn Sie es verlieren, müssen Sie eine vollständige Resynchronisierung durchführen. Kodieren Sie niemals einen Zeitbereich hart – verwenden Sie den deltaLink, um die Verarbeitung von Duplikaten oder fehlenden Änderungen zu vermeiden.
POST /ich/nachrichten/{id}/anhänge/createUploadSession) und in Blöcken hochladen. Der Versuch, einen großen Anhang inline einzufügen, führt zu einem 413 Entität zu groß Fehler.
Vermeiden Sie den Migrations-Albtraum: Ein einheitlicher E-Mail-API-Ansatz
Eine vollständige EWS-zu-Graph-Migration für eine komplexe Anwendung dauert 4 bis 8 Wochen Entwicklungszeit. Sie müssen Azure-Apps registrieren, OAuth-Flows implementieren, Token-Aktualisierung handhaben, Drosselung verwalten, jeden SOAP-Aufruf umschreiben, die Fehlerbehandlung aktualisieren und Tests über Umgebungen hinweg durchführen. Machen Sie das dann noch einmal, wenn Microsoft etwas ändert.
Unipile abstrahiert Microsoft Graph, Gmail und IMAP unter einer einzigen, einheitlichen API. Sie authentifizieren Ihre Benutzer einmal über Unipile und lesen/senden E-Mails, synchronisieren Kalender und verwalten Kontakte über alle drei Anbieter hinweg mit denselben Endpunkten – keine Azure-App-Registrierung, keine anbieterabhängigen OAuth-Flows, keine zu pflegende Drosselungslogik. Sehen Sie sich unsere Vollständige E-Mail-API-Anleitung und E-Mail-API-Anbieter-Vergleich um die Landschaft zu verstehen.
50 Zeilen Microsoft Graph vs. 5 Zeilen Unipile
// 1. Azure App-Registrierung (portal.azure.com)
// 2. OAuth-Autorisierungscode-Fluss
const authUrl = `https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/authorize?`
+ new URLSearchParams({
client_id: CLIENT_ID,
response_type: 'Code', redirect_uri: REDIRECT_URI,
scope: 'Mail.Read offline_access',
response_mode: 'Anfrage'
});
// 3. Umleitung behandeln, Code gegen Token tauschen
const tokenRes = await fetch(`https://login.microsoftonline.com/${tenantId}/oauth2/v2.0/token`, {
Methode: 'POST',
body: new URLSearchParams({
client_id: CLIENT_ID, client_secret: CLIENT_SECRET,
code: authCode, redirect_uri: REDIRECT_URI,
grant_type: 'autorisierungscode'
})
});
const { access_token, refresh_token } = await tokenRes.json();
4. Speichere + aktualisiere Tokens bei Ablauf (stündlich)
// 5. Graph-Aufruf mit Bearer-Token
const res = await fetch('https://graph.microsoft.com/v1.0/me/messages?$top=10', {
Header: { Authorization: `Bearer ${access_token}` }
});
// 6. Drosselung behandeln (HTTP 429 + Retry-After)
wenn (res.status === 429) {
const retryAfter = res.headers.bekommen.('Erneut versuchen nach');
await Schlaf(wiederholenNach* 1000);
Versuchen Sie es erneut...
}
// 7. Paginieren über @odata.nextLink
const Daten = await res.json();
lassen Nachrichten = Daten.Wert;
während (Daten['@odata.nextLink']) { /* ... */ }// Keine Azure-App, keine zu implementierenden OAuth-Flows,
// Keine Drosselungslogik, keine Token-Aktualisierung.
// Funktioniert für Outlook UND Gmail UND IMAP.
const Kunde = new UnipileClient(API-Schlüssel);
const Nachrichten = await client.email.Nachrichten auflisten({
account_id: BenutzerkontoId, // verknüpftes Konto
Ordner: 'POSTeingang',
limit: 10
});
// Gleicher Code, gleiches Antwortformat
// für Outlook, Gmail und IMAP.
// Unipile verarbeitet OAuth, Drosselung,
// Paginierung und Token-Aktualisierung.Outlook REST API & EWS - FAQ
Häufig gestellte Fragen zur Ablösung der Outlook REST API, zur Stilllegung von EWS und zur Migration zu Microsoft Graph
Nein. Die Outlook REST API (v2.0 und Beta) wurde von Microsoft eingestellt. Alle Anfragen an die alten Outlook REST Endpunkte schlagen jetzt fehl. Der offizielle Ersatz ist Microsoft Graph, welche dieselben E-Mail- und Kalenderoperationen sowie vieles mehr abdeckt. Wenn Ihre Anwendung noch Outlook REST-Endpunkte verwendet, ist die Migration zu Graph nicht optional.
Die Outlook REST-API war eine spezielle REST-API, die nur Outlook-Postfachoperationen abdeckte. Microsoft Graph ist die einheitliche API für das gesamte Microsoft 365-Ökosystem: Outlook-Mail, Kalender, Kontakte, Teams, SharePoint, OneDrive und mehr. Beide verwenden die OAuth 2.0-Authentifizierung, aber Graph verwendet die einzelne Basis-URL https://graph.microsoft.com/v1.0 und bietet eine konsistentere, funktionsreichere Oberfläche als die eingestellten Outlook-spezifischen Endpunkte.
Microsoft hat festgelegt 1. Oktober 2026 als das Datum für die strikte Durchsetzung der Abschaffung von EWS in Exchange Online (Microsoft 365). Nach diesem Datum wird EWS für Microsoft 365-Postfächer nicht mehr funktionieren. Es gibt keine Kulanzfrist und keine angekündigte Verlängerung. EWS wird weiterhin für lokale Exchange Server-Installationen funktionieren, die von dieser Frist nicht betroffen sind.
Microsoft Graph ist der offizielle Ersatz für EWS. Jede EWS-Operation hat eine Graph-Entsprechung: GegenstandSuchen wird GET /me/messages, GegenstandErstellen (E-Mail senden) POST /me/sendMail, Streaming-Benachrichtigungen werden zu Graph-Webhooks über POST /abonnements. Authentifizierungsänderungen von NTLM/Kerberos/Basic Auth zu OAuth 2.0 über Azure AD. Für Teams, die einen einfacheren Weg benötigen, ein vereinheitlichte E-Mail-API wie Unipile fasst alle drei Anbieter unter einem SDK zusammen.
Nein. Die Outlook REST API v2.0 wurde eingestellt. Anfragen an diese Endpunkte werden mit Fehlern fehlschlagen. Microsoft Graph ist der einzige unterstützte Weg für die Integration von Outlook-E-Mails und Kalendern. Alle neuen Integrationen müssen auf https://graph.microsoft.com/v1.0 und verwende OAuth 2.0-Authentifizierung.
Der Aufwand hängt von der Komplexität Ihrer EWS-Implementierung ab. Eine einfache Integration mit wenigen Lese-/Schreibvorgängen dauert in der Regel 1-2 Wochen. Eine komplexe Anwendung mit Streaming-Benachrichtigungen, Delta-Synchronisierung, Multi-Ordner-Operationen und umfangreicher Fehlerbehandlung kann 4-8 Wochen dauern. Die Migration erfordert: Azure AD App-Registrierung, OAuth 2.0-Implementierung, Ersetzung von Endpunkt zu Endpunkt, Drosselungslogik, Seitenaktualisierungen und Änderungen des Fehlerformats. Eine Alternative ist die Verwendung von Unipiles Microsoft Graph Abstraktion, das einen Großteil dieser Komplexität automatisch handhabt.
Die Frist vom Oktober 2026 gilt speziell für Exchange Web Services (EWS) Nutzung in Exchange Online. Outlook-Add-Ins, die die Office.js API verwenden, haben einen separaten Zeitplan. Microsoft stellt jedoch die alten COM- und VSTO-Add-Ins zugunsten webbasierter Office-Add-Ins ein. Wenn Ihr Add-In intern EWS-Aufrufe tätigt, werden diese Aufrufe im Oktober 2026 unterbrochen, unabhängig vom Add-In-Framework. Überprüfen Sie die Microsoft 365 Roadmap für die neuesten Anleitungen, die für Ihren Add-In-Typ spezifisch sind.
Da die Outlook REST-API eingestellt wurde, sind die relevanten Bereiche für Microsoft Graph. Kern-E-Mail-Bereiche: Mail.Lesen (Nachrichten lesen), Mail.Senden (E-Mail senden), Mail.ReadWrite (Nachrichten lesen und bearbeiten), Kalender.LesenSchreiben (Kalenderzugriff), Kontakte.Lesen (Kontakte). Immer enthalten Offline-Zugriff um ein Aktualisierungstoken zu erhalten. Anwendungsbereich wie Mail.ReadWrite.All Admin-Zustimmung vom Mandantenadministrator erfordern und nur für Daemon-Szenarien ohne Benutzerkontext verwenden. Siehe unsere Microsoft Graph OAuth-Leitfaden für eine vollständige Einrichtungsanleitung.
Microsoft Graph erzwingt Ratenbegrenzungen von ungefähr 10.000 Anfragen pro 10 Minuten pro Anwendung pro Mandanten. Wenn die API gedrosselt wird, gibt sie HTTP 429 Zu viele Anfragen with a Erneut versuchen nach Header, der die genaue Anzahl von Sekunden angibt, die gewartet werden soll. Die entscheidende Regel: immer befolgen Erneut versuchen nach genauwert. Ein erneuter Versuch vor dem Schließen dieses Fensters verlängert die Drosselungsperiode. Bei mandantenfähigen SaaS-Anwendungen, bei denen jeder Mandant getrennte Grenzwerte hat, beeinträchtigt die Drosselung bei einem Mandanten nicht die anderen. Vergleichen Sie auch IMAP als Alternative wenn Drosselung in großem Maßstab ein Problem darstellt.
Unipile ist ein Vereinheitlichte E-Mail-API damit werden Microsoft Graph, Gmail und IMAP unter einem einzigen SDK zusammengefasst. Anstatt Microsoft Graph OAuth-Flows zu implementieren, Zugriffstoken zu verwalten, Drosselung zu handhaben und pro Anbieter Code zu schreiben, verbinden Sie die Konten Ihrer Benutzer über Unipile und verwenden eine einheitliche API für alle drei Anbieter. Dies ist besonders wirkungsvoll für SaaS-Anwendungen, die Outlook und Gmail gleichzeitig unterstützen müssen, ohne separaten Integrationscode für jeden zu pflegen. Unipile agiert als unabhängiger technischer Vermittler auf Anfrag ejedes authentifizierten Benutzers und ist nicht mit Microsoft verbunden oder wird von diesem unterstützt.
Überspringen Sie die EWS-Migration vollständig. Unser Team hilft Ihnen gerne weiter.
Jetzt bauen
DE 
EN 
FR 
ES 
IT 
BR 
NL 
PL 
TR