+1 480 485 7373
Microsoft Teams
Three ways into Business Central data through the API
The standard API, currently version 2.0, is a set of REST endpoints that Microsoft maintains. It covers common entities such as companies, customers, vendors, items, sales orders, invoices, journals, ledger entries and dimensions. It follows OData conventions, returns JSON, and supports filtering and paging. Microsoft also versions it, so an integration built on it is less likely to break after an update. Start every integration here.
OData web services are the older route. An administrator publishes a page or query on the Web Services page, and it becomes an OData feed. This is quick and flexible, and it suits reading data into Excel or Power BI. However, it exposes the page as it is, including its triggers and user interface logic. Microsoft does not version it the way it versions the API. So it works for reporting feeds but makes a poor base for a critical write integration.
Custom API pages fill the gaps. A developer creates a page of type API in an AL extension and gives it a publisher, group and version. The developer also chooses which fields it exposes and how inserts and updates behave. Use this when the standard API lacks an entity or field you need. It keeps the contract stable, because you control the version.
Which interface fits which job
Setting up authentication for the Business Central API
- 1
Register an application in Entra ID
In the Azure portal, create an app registration in your tenant. Add a client secret or, better, a certificate so the service can prove its identity.
- 2
Grant the API permissions
Add the Dynamics 365 Business Central application permissions the integration needs, such as API.ReadWrite.All. Then a tenant administrator grants consent.
- 3
Register the app inside Business Central
Open the Microsoft Entra Applications page in Business Central and enter the client ID. Assign permission sets limited to what the integration touches, and grant consent.
- 4
Request a token
The service uses the OAuth 2.0 client credentials flow with the Business Central API scope. Your tenant returns an access token.
- 5
Call the environment endpoint
Requests go to the Business Central API URL for your tenant and named environment. So the same code can point at a sandbox first and production later.
Webhooks instead of constant polling
When integrating with the Business Central API, polling means asking every few minutes whether anything has changed. It works, but it wastes calls and delays reactions. Webhooks reverse the direction. Your service subscribes to an API entity, such as customers or sales invoices. Then Business Central notifies your URL when records change.
When you create a subscription, Business Central first calls your endpoint with a validation token. Your service echoes it back, which proves you control the URL. Subscriptions expire, so your service must renew them on a schedule. Also, the notification names the changed records without the full data. Your service then makes an API call to fetch the details. Build renewal and a fallback catch-up query into the design from the start.
Two more features help at volume. First, the API supports batch requests, which group several operations into one call. Second, every API record carries a last modified timestamp. A scheduled job can use it to pick up only what changed since its previous run.
Settle these before integrating with the Business Central API
System of record per field
Decide which system owns each field, such as price, credit limit or address. Then two systems never overwrite each other in a loop.
Retries and throttling
Business Central limits request rates and returns errors when a client goes over them. The client must back off and retry rather than fail silently.
Duplicate protection
Store the external ID on the Business Central record and check it before inserting. That way a retried call never creates a second order.
Error ownership
Failed messages need a queue, an alert and a named person who fixes them. Otherwise problems surface weeks later as reconciliation gaps.
Business Central API versions and authentication
Which Business Central API version should we use?
Use API version 2.0 for new work. It is the current standard API that Microsoft maintains and extends. Older version 1.0 and beta endpoints exist for backward compatibility. Do not build anything new on them. Check Microsoft's API reference for the entities and fields available today.
Can we still use basic authentication with web service access keys?
No, not for Business Central online. Microsoft retired access-key basic authentication for the online service. So integrations use OAuth through Microsoft Entra ID. Unattended services use the client credentials flow with an app registered inside Business Central. On-premises installations have their own authentication options.
API limits, custom pages and Power Automate in Business Central
Are there limits on how many API calls we can make?
Yes, Business Central online applies request limits and throttling to protect the service. Microsoft documents the exact values in its operational limits article, and they can change. So design against the current documentation, not a number from a blog post. A well-built integration batches work, uses change tracking instead of full reloads, and backs off when throttled. Those habits matter more than the specific ceiling.
Do we need a custom API page or will the standard API do?
Start with the standard API and only build a custom API page when a real gap appears. Common gaps include fields from your own extensions and entities the standard set does not cover. Some teams also need specific insert behavior. Custom API pages are straightforward AL work, but they are code you maintain. We check the standard endpoints against your field list before integrating with the Business Central API.
Is Power Automate enough, or do we need a developer?
Power Automate is enough for many moderate-volume, event-driven flows between Microsoft services and common cloud apps. It uses the same underlying APIs and removes the need to host code. High volumes, complex transformations, strict error handling or long-running synchronizations usually justify a coded integration or an integration platform. The volume and failure tolerance decide it, not preference.
Talk to us about your project.
Tell us what you run today and what has to change. A senior consultant replies with a written next step.