Microsoft Graph API with Business Central

For years, Business Central had its own dedicated OData API at api.businesscentral.dynamics.com. With Microsoft's investment in Microsoft Graph as the unified API surface across Microsoft 365 and Dynamics 365, BC is being progressively surfaced through Graph too. Understanding what's where — and when to use Graph vs BC's native APIs — matters for any cross-product integration design.

Microsoft Graph overview. A single API endpoint (graph.microsoft.com) exposing:

• M365 data — users, mail, calendar, files, Teams.
• Dynamics 365 data — customers, leads, opportunities.
• Security and compliance.
• Identity (Entra ID).
• Increasingly: Business Central data.

Graph's value is unification — one auth model, one query syntax, one SDK across many sources.

BC in Microsoft Graph. As of 2026, Graph exposes a growing subset of BC entities:

• Customers.
• Vendors.
• Items.
• Sales orders.
• Purchase orders.
• Invoices.

The list expands; check current Graph documentation for what's GA vs beta vs preview.

BC's native APIs. Continue to exist:

• Standard API v2.0 at api.businesscentral.dynamics.com/v2.0/... — comprehensive coverage.
• Custom APIs — partner-defined endpoints.
• Web services — older SOAP-style.

The native API is more complete than Graph for BC; Graph is more universal across Microsoft products.

When Graph wins for BC.

• Cross-product integrations — pulling BC + M365 + Dynamics 365 data in one app.
• App ecosystem — many apps already use Graph for M365.
• Unified auth — single token covers many resources.
• Modern SDK — Microsoft Graph SDKs in many languages.

When native API wins for BC.

• Complete BC coverage — niche entities not in Graph.
• Performance — direct API is sometimes faster.
• Specific BC behaviour — bound actions specific to BC.
• Established integrations — already built on native API.

Authentication.

• Graph — Microsoft Entra ID OAuth 2.0. App registrations grant BusinessCentral.ReadWrite.All and other scopes.
• Native — also Entra ID OAuth; same patterns.

Both surfaces require app registration; Graph's permission scopes are less granular than BC's native API (which has per-environment, per-company scoping).

Query patterns. Graph endpoints follow standard Graph conventions:

GET https://graph.microsoft.com/v1.0/financials/companies/{id}/customers

OData filtering, paging, expand all work as with M365 endpoints. The mental model: Graph is OData with Microsoft conventions; if you know Graph for M365, BC in Graph feels familiar.

Common scenarios.

• Pull BC customer + their M365 contact info — single Graph app.
• Surface BC invoices in Outlook — Outlook add-in queries Graph.
• Aggregate BC + Sales data in a custom app — Graph for both.
• Power Automate flow touching BC and SharePoint — Graph connectors for both.

Webhooks via Graph. Graph supports change notifications:

• Subscribe to BC entity changes.
• Notifications POSTed to your endpoint.
• Up to 4230 minutes (3 days) expiration; renewable.

Graph webhooks are simpler than BC's native webhook setup but cover fewer entity types currently.

Rate limiting. Graph and BC both have throttling:

• Graph — generous; throttle messages with Retry-After header.
• BC native — environment-level limits; expect 429 responses on heavy load.

Apps must respect throttle headers and back off.

Coverage map. Microsoft publishes documentation listing which BC entities are in Graph (status: GA / preview / beta) and which are only in native. Before designing an integration, verify the entity you need is in Graph at your chosen status level.

Versioning.

• Graph v1.0 — stable, GA endpoints.
• Graph beta — preview endpoints; may change.

For production, prefer v1.0; beta for experimentation and feature requests.

Common pitfalls.

• Assuming Graph has everything. Niche BC features missing from Graph; the integration breaks when it hits them.
• Mixing Graph and native. Two APIs in one integration; ambiguity about which to use when; complexity.
• Permission scope confusion. Graph permissions vs BC permissions; admin grants Graph but not the underlying BC access.
• Webhook configuration drift. Webhook expires; not renewed; events missed.
• Beta in production. Beta endpoints change without notice; integrations break.
• Latency assumptions. Cross-product queries through Graph can be slower than direct BC API; budget for it.

Strategic positioning. Microsoft's investment is in Graph as the unified surface. Over time, more BC functionality will appear there; new development should default to Graph for cross-product scenarios. Native BC APIs remain the right choice for BC-only deep integrations. Most production integrations end up using both — Graph for cross-product, native for BC-specific operations. Designing the integration to be agnostic to the API surface (with a thin wrapping layer in code) preserves flexibility as Microsoft's API strategy evolves.

Operational guidance. For new integrations: check Graph first; use native only when Graph doesn't cover the need. For existing integrations on native: don't migrate just for the sake of it; migrate when you're touching the code for other reasons or when Graph adds compelling new capabilities.