Microsoft hat den Termin gesetzt: Mit Dynamics 365 Business Central 2026 Release Wave 1 (Version 28, kurz BC28) wird die API v1.0 endgültig aus Business Central entfernt (Microsoft Learn, 2026). Genau über diese Schnittstelle hängen viele Online-Shops bis heute an Business Central -- für die Synchronisation von Artikeln, Beständen, Preisen und Bestellungen. Schon in 2024 Release Wave 1 wurde die API v1.0 als veraltet markiert, mit der Ankündigung der Entfernung in 2026 Release Wave 1 (Microsoft Learn, 2026). Wer die Frist verstreichen lässt, riskiert, dass die Bestell-, Artikel- und Bestandssynchronisation zwischen ERP und Shop bricht. Dieser Artikel zeigt, was die v1.0-Abkündigung konkret für Dynamics-365-Shop-Integrationen bedeutet, wie der Umstieg auf API v2.0 und eine saubere REST-Connector-Architektur abläuft, welche neuen 2026-Connector-Funktionen dazukommen und wie ein belastbarer Migrationsfahrplan aussieht. Anders als unser Grundlagenartikel zur Erst-Anbindung von Business Central an den Shop geht es hier gezielt um die Migration bestehender Connector auf die neue API-Generation.
Das Wichtigste in Kürze
- Mit Business Central 2026 Release Wave 1 (Version 28) entfernt Microsoft die API v1.0, der Rollout startet im April 2026 (Microsoft Learn, 2026). Jeder Aufruf gegen /api/v1.0/ liefert danach keine Daten mehr.
- Bleibt die Umstellung aus, aktualisieren sich Bestände im Shop nicht mehr, neue Bestellungen laufen nicht ins ERP und Preisänderungen kommen nicht an. Laut Microsoft enthält v2.0 den vollen Funktionsumfang von v1.0, die Migration ist also machbar (Microsoft Learn, 2026).
- Der Umstieg ist kein URL-Tausch: v2.0 ersetzt Mehrteil- und Nicht-GUID-Schlüssel durch GUIDs mit Abruf über die unveränderliche SystemId, löst verschachtelte Felder wie address in Felder erster Ebene auf und liefert Optionsfelder als typisierte Enums.
- Bewährt ist ein zweigeteilter Betrieb: Bestellungen per Event sofort als Sales Order, Artikel, Preise und Bestände zeitgesteuert als Delta über $filter auf den Änderungszeitstempel. Authentifiziert wird über OAuth2 mit Microsoft Entra ID statt Basic-Auth.
- Die 2026er Connector-Generation synchronisiert Bilder je Produktvariante, nutzt bis zu drei Item-Attribute als Produktoptionen und übernimmt den beim Checkout gezahlten Betrag in Fremdwährung ohne Umrechnung (azurecurve, 2026).
- Der Fahrplan hat vier Phasen: Audit aller v1.0-Aufrufe inklusive interner Bibliotheken, Umbau von Schlüssellogik und Mapping, Test im Sandbox-Parallelbetrieb mit realen Datenmengen und kontrolliertes Umschalten vor dem BC28-Update.
Was die v1.0-Abkündigung für Shop-Integrationen bedeutet
Die API v1.0 von Business Central etablierte den Standardweg, über den externe Systeme per REST mit dem ERP kommunizieren -- darunter E-Commerce-Plattformen, Power-Platform-Anwendungen, Azure Data Lake und CRM-Integrationen (ArcherPoint, 2026). Microsoft selbst beschreibt diesen Mechanismus über sogenannte Connect Apps, die eine Punkt-zu-Punkt-Verbindung zwischen Business Central und Drittlösungen herstellen (Microsoft Learn, 2026). Mit BC28 fällt dieser v1.0-Endpunkt weg. Für eine Shop-Integration heißt das: Jeder Aufruf, der noch gegen /api/v1.0/ läuft, liefert nach dem Update keine Daten mehr.
Business Central erscheint regelmäßig in zwei großen Release-Wellen pro Jahr; 2026 Release Wave 1 wird ab April 2026 ausgerollt und deckt die Funktionen von April bis September 2026 ab (Microsoft Learn, 2026). In Online-Umgebungen werden Updates planmäßig eingespielt -- ein Aufschieben über die regulären Update-Fenster hinaus ist nur begrenzt möglich. Deshalb sollte die Migration nicht erst zum Stichtag beginnen. Eine fehlerhafte Datenintegration zählt branchenübergreifend zu den größten ERP-Herausforderungen: 62 Prozent (Panorama Consulting, 2025) der Unternehmen nennen die Integration von Daten als zentrales Problem in ERP-Projekten, und 68 Prozent (DATAVERSITY, 2024) sehen Datensilos als größte Hürde.
Was bei verschlafener Migration konkret passiert
API v1.0 oder API v2.0: die wichtigsten Unterschiede
Die API v2.0 wurde bereits in 2020 Release Wave 2 eingeführt und ist die langfristig gepflegte, versionierte Generation der Business-Central-Schnittstelle (Microsoft Learn, 2026). Die Unterschiede zur v1.0 sind nicht kosmetisch -- sie betreffen Schlüssel, Datenstruktur und Typisierung. Wer migriert, passt deshalb nicht nur die URL an, sondern stellt das Mapping im Connector um.
| Aspekt | API v1.0 (entfällt mit BC28) | API v2.0 (Standard) |
|---|---|---|
| Schlüssel | Multipart- und Nicht-GUID-Schlüssel bei vielen Entitäten | Einheitliche GUID-Schlüssel, Abruf über SystemId |
| SystemId | Nicht durchgängig als Primärschlüssel | Unveränderlich, plattformseitig erzwungen, indexiert |
| Komplexe Felder | Verschachtelte JSON-Objekte (z. B. address) | Felder erster Ebene oder Navigationseigenschaften |
| Mengeneinheit | baseUnitOfMeasure als komplexes Feld | unitOfMeasure als Navigationseigenschaft via $expand |
| Optionsfelder | Als String ausgegeben | Stark typisierte Enums (z. B. für Dropdowns) |
| Empfehlung | Wird entfernt -- nicht mehr nutzen | Standard für Integrationen |
Der wohl folgenreichste Unterschied betrifft die Schlüssel. In v1.0 nutzten Entitäten wie salesOrderLines, salesInvoiceLines oder defaultDimensions Mehrteil- oder Nicht-GUID-Schlüssel. In v2.0 werden alle diese Schlüssel durch eindeutige GUIDs ersetzt, und Datensätze lassen sich über die SystemId abrufen -- ein unveränderlicher, plattformseitig erzwungener und indexierter Wert, der Auditing und Lesegeschwindigkeit verbessert (Microsoft Learn, 2026). Für den Connector bedeutet das: Verknüpfungen, die bislang auf Belegnummer plus Zeilennummer aufgebaut waren, müssen auf GUID-Referenzen umgestellt werden.
Ein zweiter Punkt sind die komplexen Eigenschaften. In v1.0 lieferte etwa das Feld address ein verschachteltes JSON-Objekt zurück, weil die Werte zur Laufzeit berechnet wurden. In v2.0 werden diese komplexen Eigenschaften durch Felder erster Ebene (etwa addressLine1, city, postalCode) oder durch Navigationseigenschaften ersetzt -- das verbessert die Performance erheblich, weil keine Laufzeitberechnung mehr nötig ist (Microsoft Learn, 2026). Die Mengeneinheit eines Artikels etwa wird nicht mehr als verschachteltes baseUnitOfMeasure geliefert, sondern als Navigationseigenschaft unitOfMeasure, die per $expand optional eingebunden wird.
GET /api/v1.0/companies({id})/customers({id})
{
"number": "10000",
"displayName": "Beispiel GmbH",
"address": {
"street": "Marktplatz 1",
"city": "Hannover",
"postalCode": "30159"
}
}GET /api/v2.0/companies({id})/customers({id})
{
"id": "<systemId-guid>",
"number": "10000",
"displayName": "Beispiel GmbH",
"addressLine1": "Marktplatz 1",
"city": "Hannover",
"postalCode": "30159"
}Schließlich werden Optionsfelder in v2.0 als stark typisierte Enums ausgegeben statt als freie Strings (Microsoft Learn, 2026). Das erlaubt es dem Connector, die zulässigen Werte etwa für Dropdown-Anzeigen zuverlässig zu bestimmen, statt Werte fest zu verdrahten. Für die langfristige Versionierung von Schnittstellen ist gerade dieser Aspekt wertvoll, weil neue Optionswerte nicht sofort Code-Änderungen erzwingen.
REST-Connector-Architektur: Real-time und Scheduled
Ein robuster Shop-Connector für Business Central kombiniert in der Regel zwei Betriebsmodi. Real-time-Synchronisation reagiert auf Ereignisse, die sofort wirken müssen -- typischerweise neue Bestellungen aus dem Shop, die unmittelbar als Sales Order im ERP entstehen sollen. Scheduled-Synchronisation läuft in festen Intervallen und eignet sich für Datenmengen, die nicht sekundengenau aktuell sein müssen, etwa Preislisten oder den gesamten Artikelstamm.
In der Praxis empfiehlt sich eine entkoppelnde Middleware zwischen Business Central und Shop, statt jeden Datenfluss als starre Punkt-zu-Punkt-Verbindung zu bauen. Die Middleware kapselt die OAuth2-Authentifizierung über Microsoft Entra ID, das Feld-Mapping, eine Warteschlange für Lastspitzen und das Monitoring an einer einzigen Stelle. Welche Architektur im Einzelfall passt, hängt von der Systemlandschaft ab -- das beleuchten wir ausführlich im Vergleich von REST-API und Middleware.
Real-time: Bestellungen
Neue Shop-Bestellungen werden per Event sofort als Sales Order in Business Central angelegt -- ohne manuelles Abtippen und ohne Verzögerung im Auftragseingang.
Scheduled: Stammdaten
Artikel, Preise und Bestände werden in Intervallen abgeglichen. Über $filter auf den Änderungszeitstempel werden nur geänderte Datensätze geladen (Delta-Sync).
OAuth2 statt Basic-Auth
Authentifizierung über Microsoft Entra ID mit kurzlebigen Tokens. Die frühere Basic-Authentifizierung wird für neue Integrationen nicht mehr empfohlen.
GUID-basiertes Mapping
Verknüpfungen zwischen Shop- und ERP-Datensätzen laufen über SystemId-GUIDs statt über Beleg- und Zeilennummern -- stabil über Updates hinweg.
Queue und Retry
Eine Warteschlange mit Retry und Exponential Backoff respektiert die API-Drosselung von Business Central und stellt sicher, dass keine Bestellung verloren geht.
Monitoring der Flüsse
Zentrales Logging und Alarmierung machen sichtbar, ob ein Sync durchläuft -- die Basis für eine belastbare Observability der Schnittstellen.
GET /api/v2.0/companies({id})/items
?$filter=lastModifiedDateTime gt 2026-07-03T06:00:00Z
&$select=number,displayName,unitPrice
&$orderby=lastModifiedDateTime
Authorization: Bearer <access_token>Neue 2026-Connector-Funktionen, die sich lohnen
Die 2026er Generation des Business-Central-Shop-Connectors bringt nicht nur die neue API-Basis, sondern auch funktionale Erweiterungen, die für Online-Shops im Tagesgeschäft spürbar sind (azurecurve, 2026). Wer ohnehin migriert, kann diese Funktionen gleich mit aktivieren.
Bilder für Produktvarianten
Bilder von Artikelvarianten in Business Central werden mit den entsprechenden Produktvarianten im Shop synchronisiert -- pro Variante statt nur ein Hauptbild (azurecurve, 2026).
Item-Attribute als Optionen
Beim Export lassen sich bis zu drei Item-Attribute als Produktoptionen festlegen, etwa Farbe, Größe oder Material -- Grundlage für saubere Varianten im Shop (azurecurve, 2026).
Checkout-Währung
Für Multi-Currency-Szenarien wird der beim Checkout gezahlte Betrag exakt übernommen, ohne unnötige Währungsumrechnung beim Anlegen der Verkaufsbelege (azurecurve, 2026).
Die aktuelle Connector-Generation stützt sich zudem auf eine im Januar 2026 veröffentlichte API-Version der jeweiligen Shop-Plattform, was zuverlässigere Bestandsaktualisierungen, eine bessere Verarbeitung großer Produktkataloge und klarere Retouren- sowie Auszahlungsinformationen mit sich bringt (azurecurve, 2026). Für Kataloge mit zehntausenden Artikeln und vielen Varianten ist gerade die verbesserte Massenverarbeitung relevant -- ein Punkt, der eng mit einer sauberen Produktdaten-Pipeline und PIM-Integration zusammenhängt.
Migration als Gelegenheit nutzen
Risiko-Check: wie betroffen ist Ihr Connector
Bevor ein Migrationsprojekt startet, lohnt eine ehrliche Bestandsaufnahme. Die folgende Prüfliste hilft, das Risiko einzuschätzen, das mit dem BC28-Update auf eine bestehende Shop-Anbindung zukommt.
- Laufen Synchronisations-Aufrufe noch gegen
/api/v1.0/-Endpunkte oder über einen Konnektor, der intern v1.0 nutzt? - Werden Verknüpfungen zwischen Shop und ERP über Beleg- und Zeilennummern statt über GUID-Schlüssel hergestellt?
- Verlässt sich der Code auf verschachtelte Felder wie address oder baseUnitOfMeasure aus der v1.0-Antwortstruktur?
- Werden Optionsfelder als feste Strings ausgewertet, die in v2.0 zu Enums werden?
- Existiert eine Test- oder Sandbox-Umgebung, in der die Migration vor dem Produktiv-Update geprüft werden kann?
- Ist dokumentiert, welche Entitäten (Artikel, Preise, Bestände, Bestellungen, Kunden) in welcher Richtung synchronisiert werden?
Je mehr Punkte unklar bleiben, desto dringender ist eine frühzeitige Analyse. Erfahrungsgemäß unterschätzen Teams den Aufwand für das Umstellen der Schlüssel-Logik, weil GUID-Referenzen die bisherige Zuordnung über Nummern ersetzen. Wer hier sauber arbeitet, beugt zugleich klassischen Integrationsfehlern vor -- denn manuelle Dateneingabe bringt erfahrungsgemäß Fehlerraten um 1 Prozent (Conexiom, 2024) mit sich, während integrierte Prozesse Order-to-Cash-Genauigkeiten von über 99 Prozent (Conexiom, 2024) erreichen können.
Der Migrationsfahrplan in vier Phasen
Eine Migration von API v1.0 auf v2.0 lässt sich in vier überschaubare Phasen gliedern. Entscheidend ist, dass der Umstieg vor dem BC28-Update abgeschlossen und in einer Testumgebung verifiziert ist -- nicht erst dann, wenn die alte Schnittstelle bereits abgeschaltet wurde.
- Audit und Inventur: Alle Stellen identifizieren, an denen der Connector v1.0 nutzt -- inklusive interner Bibliotheken. Entitäten, Richtungen und Intervalle dokumentieren.
- Umbau und Mapping: Endpunkte auf v2.0 umstellen, Schlüssel-Logik auf GUID und SystemId migrieren, verschachtelte Felder auf Felder erster Ebene beziehungsweise $expand-Navigationseigenschaften umstellen und Optionsfelder als Enums behandeln.
- Test im Parallelbetrieb: In einer Sandbox die v2.0-Synchronisation gegen reale Datenmengen testen, Delta-Abfragen und Drosselung prüfen und Bestell-, Artikel- sowie Bestandsflüsse end-to-end durchspielen.
- Umschalten vor BC28: Den Produktiv-Connector kontrolliert auf v2.0 umstellen, Monitoring scharf schalten und erst danach das BC28-Update einplanen -- so bleibt die Synchronisation durchgängig verfügbar.
Im Rahmen der Migration sollten auch Idempotenz und Wiederholbarkeit der Abläufe geprüft werden, damit ein erneuter Versuch nach einem Fehler keine Dubletten erzeugt -- ein Thema, das wir im Detail bei Idempotenz und Retry-Strategien behandeln. Für bestehende Anbindungen, die wir betreuen, übernehmen wir Audit, Umbau und kontrollierte Umschaltung als geführtes Projekt über unsere Dynamics-365-Shop-Integration.
Eine API-Abkündigung ist selten ein Notfall -- sie wird erst dann zu einem, wenn man bis zum Stichtag wartet. Wer die Migration als planbares Projekt führt, behält die Kontrolle über Daten, Termine und Kosten.
Quellen und Studien