Business Central Schnittstellen: API, OData und Webhooks im Vergleich

Business Central bietet mehrere Wege, Daten mit anderen Systemen auszutauschen: die Standard-REST-API v2.0, eigene API-Pages und API-Queries in AL, OData-Webservices, Webhooks, Power Automate und den klassischen Dateiimport. Microsoft empfiehlt für neue Integrationen ausdrücklich REST-API-Webservices, SOAP gilt als abgekündigt. In Business Central Online ist die Anmeldung per OAuth 2.0 über eine Microsoft-Entra-App Pflicht, Basic Auth mit Webdienst-Zugriffsschlüssel wird dort nicht mehr unterstützt.

Ich arbeite seit 2014 mit Navision und Business Central und entwickle unter anderem Schnittstellen zu Versanddienstleistern, Payment-Anbietern und Shopsystemen. In diesem Artikel ordne ich die Integrationswege ein, zeige, wann welcher passt, und wo die Grenzen liegen. Stand: Oktober 2026.

Welche Integrationswege gibt es in Business Central?

Es gibt sieben gängige Wege, die sich in Richtung (wer stößt den Austausch an), Aufwand und Robustheit unterscheiden:

1. Standard-API v2.0: fertige REST-Endpunkte von Microsoft für Kunden, Artikel, Verkaufsaufträge, Rechnungen und weitere Entitäten.
2. Eigene API-Pages und API-Queries: in einer AL-Extension entwickelte REST-Endpunkte mit genau den Feldern und der Logik, die eure Anbindung braucht.
3. OData-Webservices: normale Pages, Queries oder Codeunits, die über die Seite Webdienste veröffentlicht werden.
4. Webhooks: Business Central benachrichtigt ein externes System, sobald sich ein Datensatz ändert.
5. Business Events: neuere, ereignisbasierte Integration, vor allem über Dataverse und Power Automate, per API aber auch für andere Systeme abonnierbar.
6. Power Automate: Low-Code-Flows über den Business-Central-Connector.
7. Dateiimport und -export: CSV, XML oder feste Formate, zum Beispiel per XMLport.

Welcher Weg der richtige ist, hängt weniger von der Technik ab als von der Frage, wie aktuell die Daten sein müssen, wie viel Logik im ERP passieren soll und wer die Schnittstelle langfristig betreut.

Vergleich: Methode, geeignet für, Grenzen

Standard-API v2.0: der erste Blick

Die Standard-API v2.0 ist der Ausgangspunkt für fast jede Integration, weil sie ohne Entwicklung verfügbar ist und von Microsoft gepflegt wird. Sie stellt REST-Endpunkte für gängige Entitäten wie customers, items, salesOrders oder salesInvoices bereit. Die Übersicht der Endpunkte findet ihr in der API-Referenz v2.0 bei Microsoft Learn.

Für viele Standardszenarien reicht das. Sobald ihr aber eigene Felder aus einer Extension, Branchenlogik oder Daten aus mehreren Tabellen in einem Aufruf braucht, stößt die Standard-API an ihre Grenzen. Dann kommt eine eigene API ins Spiel.

Eigene API-Pages und API-Queries in AL

Eigene APIs sind in den meisten individuellen Anbindungen der sauberste Weg: Ihr bestimmt Felder, Filter und Validierung selbst, und das Ergebnis ist ein versionierter REST-Endpunkt. Technisch entsteht das als Page vom Typ API oder als Query vom Typ API in einer AL-Extension, mit eigenem Publisher, eigener Gruppe und Version im Pfad, etwa /api/meinpublisher/meinegruppe/v1.0/. Microsoft beschreibt das Vorgehen unter Entwickeln einer benutzerdefinierten API sowie in den Referenzen zum API-Page-Typ und API-Query-Typ.

Wichtige Punkte aus meiner Praxis:

• Versionierung von Anfang an: Ändert sich die Struktur, legt ihr eine neue Version an, statt die bestehende zu brechen. Das externe System kann dann in Ruhe umstellen.
• Geschäftslogik in Codeunits, nicht in der API-Page: Die Page nimmt Daten entgegen, die Verarbeitung passiert in testbarem AL-Code.
• Updates im Blick behalten: Eine API in einer Extension muss mit jedem Business-Central-Update kompatibel bleiben. Was passiert, wenn das schiefgeht, beschreibe ich in Extension nach Update nicht kompatibel.

Ob eine Anforderung überhaupt eine eigene Extension braucht oder sich mit Standardmitteln lösen lässt, ist eine eigene Abwägung. Dazu passt der Artikel Extension oder Anpassung im Standard.

OData-Webservices: was Microsoft empfiehlt

OData-Webservices funktionieren weiterhin, sind für neue Integrationen aber nicht mehr die erste Wahl. Microsoft schreibt in der Übersicht zu Webdiensten in Business Central, dass REST-API-Webservices der empfohlene Weg sind, um Webservices zu entwickeln und zu nutzen. Normale UI-Pages über die Seite Webdienste zu veröffentlichen bleibt möglich, birgt aber ein Risiko: Code auf der Page, etwa für FactBoxen, läuft auch beim Webservice-Aufruf mit und kann die Antwortzeiten verschlechtern. Laut der Microsoft-Liste abgekündigter Plattformfunktionen lassen sich ab Version 30 (2027 Release Wave 1) Microsoft-Pages, also Pages aus Apps mit dem Publisher Microsoft wie der Base Application, nicht mehr als OData-Endpunkt veröffentlichen. Wer solche Integrationen braucht, muss die Page in eine eigene Extension übernehmen oder besser auf API-Pages umstellen. Stand: Oktober 2026.

Für Power BI führt Microsoft OData-Webservices nur noch als Legacy-Methode, die Power Platform unterstützt ausschließlich API-Webservices. Die technischen Details zu OData V4 findet ihr unter OData-Webservices.

SOAP ist abgekündigt. Laut Microsoft-Dokumentation zu SOAP-Webservices wird die Unterstützung in einem kommenden Release entfernt. Microsoft-UI-Pages lassen sich seit Version 29.0 (2026 Release Wave 2) gar nicht mehr als SOAP-Webservice veröffentlichen. Microsoft empfiehlt den Umstieg auf OData V4 oder bevorzugt auf API-Pages und -Queries. Wer noch Codeunits per SOAP anbietet, kann diese meist durch OData-Unbound-Actions ersetzen. Stand: Oktober 2026.

Webhooks: Benachrichtigung statt Polling

Webhooks lösen das Problem, dass ein externes System sonst regelmäßig nachfragen müsste, ob sich etwas geändert hat. Ein externes System registriert per POST auf den Endpunkt subscriptions eine Benachrichtigungs-URL für eine Ressource, zum Beispiel Kunden oder Verkaufsaufträge. Ändert sich ein Datensatz, ruft Business Central diese URL auf. Die Details stehen in der Webhook-Dokumentation von Microsoft.

Was ihr beim Einsatz wissen solltet:

1. Handshake: Beim Anlegen und Verlängern sendet Business Central einen validationToken, den der Empfänger mit Status 200 zurückgeben muss.
2. Ablauf nach drei Tagen: Abonnements laufen ab, wenn sie nicht per PATCH verlängert werden. Ohne automatische Verlängerung bleibt die Integration irgendwann still stehen.
3. Verzögerung: Benachrichtigungen werden nicht sofort verschickt. Standardmäßig wartet Business Central 30 Sekunden nach der ersten Änderung, um mehrere Änderungen zu bündeln.
4. Nur ein Hinweis: Die Benachrichtigung enthält die Art der Änderung und die betroffene Ressource. Die eigentlichen Daten holt das externe System anschließend per API ab.
5. Eigene APIs: Auch eigene API-Pages können Webhooks auslösen, allerdings nicht in jeder Konstellation, etwa bei temporären Quelltabellen.

Business Events und Power Automate

Business Events sind Microsofts neuerer Ansatz für ereignisgesteuerte Integration: Business Central meldet fachliche Ereignisse, etwa eine gebuchte Rechnung, vor allem an Dataverse, per API-Abonnement aber auch an andere Systeme, und andere Anwendungen reagieren darauf. Microsoft führt die Funktion in der Übersicht zu Business Events als Vorschau (Preview); Inhalt und Funktionsumfang können sich noch ändern. Für produktive Kernprozesse würde ich das vorab genau prüfen. Stand: Oktober 2026.

Power Automate eignet sich für einfache Abläufe ohne eigene Entwicklung, etwa eine Benachrichtigung bei neuen Aufträgen oder einen Freigabeprozess. Microsoft beschreibt die Möglichkeiten in der Übersicht zu Power Automate mit Business Central. Sobald ein Flow viele Datensätze verarbeitet, Fehler sauber behandeln oder Daten zwischen mehreren Systemen abgleichen muss, ist eine entwickelte Schnittstelle meist wartbarer.

Dateiimport: nicht modern, aber oft nötig

Der Dateiaustausch bleibt sinnvoll, wenn die Gegenseite keine API anbietet oder große Datenmengen in Stapeln kommen. In AL wird das typischerweise über XMLports oder eigene Import-Codeunits umgesetzt. Der Nachteil: Kein Echtzeitaustausch, und Fehler in der Datei fallen oft erst beim Import auf. Eine gute Dateischnittstelle protokolliert deshalb jede Zeile und lässt fehlerhafte Datensätze gezielt nachbearbeiten.

Authentifizierung: OAuth und Microsoft Entra

In Business Central Online ist OAuth 2.0 die einzige unterstützte Anmeldung für Webservices. Laut Microsoft-Übersicht zu Webdiensten ist die Nutzung von Zugriffsschlüsseln (Basic Auth) seit Oktober 2022 abgekündigt und wird in Business Central Online nicht unterstützt.

Für Schnittstellen ohne Benutzerinteraktion nutzt ihr die Service-to-Service-Authentifizierung (S2S) mit dem OAuth-Client-Credentials-Flow:

1. App-Registrierung in Microsoft Entra ID anlegen und ein Geheimnis oder Zertifikat hinterlegen.
2. API-Berechtigungen für Business Central erteilen und die Administratorzustimmung geben.
3. In Business Central die Seite Microsoft Entra-Anwendungen öffnen, die Client-ID eintragen und passende Berechtigungssätze zuweisen.
4. Das externe System holt sich ein Token und ruft damit die API auf.

Die Schritte im Detail beschreibt Microsoft unter Verwenden von OAuth zur Autorisierung von Webdiensten und Service-to-Service-Authentifizierung. Mein Rat: Vergebt der App nur die Berechtigungen, die die Schnittstelle wirklich braucht. SUPER lässt sich Entra-Apps ohnehin nicht zuweisen, Microsoft verlangt hier ausdrücklich das Prinzip der minimalen Rechte.

Grenzen und Drosselung in Business Central Online

Business Central Online begrenzt die Zahl gleichzeitiger und aufeinanderfolgender OData-Anfragen. Wird ein Limit überschritten, antwortet der Server mit HTTP 429 (Too Many Requests). Die aktuellen Werte, die inzwischen teilweise pro Benutzer gelten, stehen bei den Betriebsgrenzen für Business Central Online. Eine robuste Schnittstelle wertet 429-Antworten aus, wartet und versucht es erneut, statt Daten zu verlieren.

Typische Anbindungen aus der Praxis

Typische Anbindungen fallen in drei Gruppen, die sich technisch ähneln:

• Versanddienstleister: Versanddaten aus Business Central an das Versandsystem übergeben, Etiketten und Sendungsnummern zurückschreiben. Ein Beispiel mit automatischer Versandklassifizierung zeigt meine Case Study zur Versandanbindung.
• Payment-Anbieter: Zahlungseingänge abrufen und offenen Posten zuordnen, häufig als Kombination aus API-Abruf und Ausgleichslogik in AL.
• Shopsysteme: Artikel, Preise und Bestände in den Shop, Bestellungen zurück als Verkaufsaufträge. Wie das konkret aussieht, beschreibe ich unter Business Central Schnittstelle zu Shopify.

Beispiel: Ein Shop meldet neue Bestellungen per eigenem Endpunkt an Business Central, Business Central legt den Auftrag an und informiert das Versandsystem nach der Lieferung über einen Webhook oder einen eigenen Aufruf. Die Kunst liegt weniger in einzelnen Aufrufen als in Fehlerbehandlung, Protokollierung und doppelten Datensätzen.

Häufige Fragen

Was ist der Unterschied zwischen API und OData in Business Central?

Beide laufen technisch über REST mit dem OData-V4-Protokoll. Eine API, also die Standard-API v2.0 oder eine eigene API-Page bzw. API-Query, ist ein versionierter Endpunkt, der von der Oberfläche entkoppelt ist. Ein OData-Webservice veröffentlicht dagegen eine normale Page oder Query über die Seite Webdienste, inklusive der UI-Logik dieser Page. Microsoft empfiehlt für neue Integrationen API-Webservices, und ab Version 30 (2027 Release Wave 1) lassen sich Microsoft-Pages nicht mehr als OData-Endpunkt veröffentlichen. Stand: Oktober 2026.

Brauche ich für eine Business-Central-Schnittstelle immer eine eigene Extension?

Nein. Wenn die Standard-API v2.0 alle benötigten Felder liefert und die Gegenseite sie direkt nutzen kann, reicht der Standard. Eine eigene Extension mit API-Pages wird nötig, sobald eigene Felder, eigene Tabellen oder zusätzliche Prüfungen und Verarbeitungslogik im ERP gebraucht werden.

Kann ich weiterhin OData-Webservices nutzen?

Ja, OData V4 wird weiterhin unterstützt. Microsoft empfiehlt für neue Integrationen aber REST-API-Webservices, also die Standard-API oder eigene API-Pages und -Queries. Läuft eine bestehende OData-Integration über eine Microsoft-Standardpage (etwa aus der Base Application), solltet ihr sie bald auf API-Pages umstellen. Ab Version 30 (2027 Release Wave 1) lassen sich Microsoft-Pages laut Microsoft nicht mehr als OData-Endpunkt veröffentlichen. Stand: Oktober 2026.

Funktioniert Basic Auth noch mit Business Central?

In Business Central Online nicht. Zugriffsschlüssel für Webservices sind seit Oktober 2022 abgekündigt und dort nicht mehr unterstützt, die Anmeldung läuft über OAuth 2.0 mit einer Microsoft-Entra-App. On-Premises-Installationen haben eigene Anmeldeoptionen, die von der Konfiguration abhängen.

Kannst du eine bestehende Schnittstelle übernehmen, die ein anderer Partner gebaut hat?

Ja. Ich analysiere zuerst den vorhandenen AL-Code, die Authentifizierung und die Fehlerprotokolle und sage euch dann, ob sich die Schnittstelle sinnvoll weiterführen lässt oder neu aufgesetzt werden sollte. Eine erste Diagnose bekommt ihr innerhalb von 48 Stunden.

Was kostet eine Schnittstellenentwicklung bei dir?

Ich arbeite zum Festpreis oder nach Aufwand ab 120 € pro Stunde, ohne Jahresvertrag und ohne Mindestabnahme. Den Umfang klären wir im kostenlosen 30-minütigen Erstgespräch.

Wann ich helfen kann

Wenn ihr eine neue Anbindung an Business Central plant, eine bestehende Schnittstelle von SOAP oder Basic Auth umstellen müsst oder Daten zwischen Shop, Versand und ERP nicht zuverlässig ankommen, sprecht mich an. Im kostenlosen Erstgespräch (30 Minuten) schauen wir auf beide Seiten der Schnittstelle, und ihr erfahrt, welcher Integrationsweg passt und ob ein Festpreis möglich ist. Sonst arbeite ich ab 120 €/h nach Aufwand, ohne Jahresvertrag. Mehr zu meinen Projekten: Schnittstellenentwicklung für Business Central.

Erstgespräch buchen