The Business Central API serves the same purpose as other APIs, which allows communication between two systems. It connects Dynamics 365 Business Central to your e-commerce store, CRM, payroll, or reporting tools, so people stop re-keying the same data in three places.
Quick answer: What is the Business Central API? The Business Central API is a set of REST (OData v4) endpoints that let other applications read and write Business Central data, such as customers, items, sales orders, and general ledger entries, over HTTPS. In Business Central Online, access is secured with Microsoft Entra ID and OAuth 2.0.
Table of Contents
- What is an API in Business Central?
- Exploring the Different API Versions in Business Central
- Business Central Online vs On-Premises: API setup
- What is the importance of APIs in Business Central?
- Standard APIs vs. Custom APIs
- Can You Extend Standard APIs?
- Business Central API integration examples for Canadian businesses
- Security, best practices, and throttling for API Management in Business Central
- What Role Does Dynamics Square Play?
- Frequently Asked Questions
The purpose of integration can differ, but the technology behind integration is the same: API. In this article, we will explore API Business Central, its setup process, types, and more.
What is an API in Business Central?
In Business Central, an API is a collection of procedures, tools, and protocols to create software applications that allow Business Central and other systems to communicate.
Developers can automate processes and improve features without requiring human interaction by using APIs to access and connect Business Central data with third-party apps.
For instance, a Business Central REST API example might involve retrieving Party Programming sales order data from Business Central and pushing it to an e-commerce platform like Shopify.
Exploring the Different API Versions in Business Central
As Business Central evolves, so do its APIs. Microsoft Dynamics 365 Business Central initially started with a beta API version in Dynamics NAV 2018, and today, API v2.0 is the standard. The different versions reflect improvements in security, performance, and functionality. Here’s a quick rundown of the versions:
Beta API (NAV 2018): Introduced as a preview and now deprecated.
API v1.0 (Business Central 14 and onwards): The first stable API version, though it's gradually being replaced by v2.0.
API v2.0 (Business Central 17 and onwards): This version comes with improved integration capabilities and system-managed fields like “Created By” and “Modified By,” eliminating the need for manual ID management.
It’s strongly recommended to use the latest Business Central API, v2.0, as it offers the latest performance and security improvements. For a detailed comparison of API versions and their features, read Business Central API Documentation.
Business Central Online vs On-Premises: API setup
Most Canadian companies we work with in Ontario, British Columbia, and Quebec are on Business Central Online (SaaS), where there is nothing to enable. The setup depends on where you run Business Central.
| Business Central Online (SaaS) | Business Central On-Premises | |
| Enable API services. | Already on. Nothing to switch on. | Enable OData and API services on the server, instance with PowerShell. |
| Authentication | Microsoft Entra ID with OAuth 2.0. Basic authentication (web service access keys) is deprecated for SaaS. | Entra ID/OAuth 2.0 can be configured; other methods depend on your server setup. |
| Base URL | api.businesscentral.dynamics.com (Microsoft-hosted) | Your own server address and port (default 7048) |
| Firewall | Not your concern. Microsoft hosts the endpoint. | Open the port to the systems that will call the API. |
| Limits | Microsoft applies throttling and operational limits per environment and user. | You control server resources, so limits depend on your hardware. |
| Best fit | Most Canadian SMBs | Companies with data residency or network restrictions |
What is the importance of APIs in Business Central?
In the Dynamics 365 Business Central ecosystem, APIs are essential for several reasons:
1. Integration with Third-Party Programs: Dynamics BC can easily integrate with other programs, including financial tools, e-commerce platforms, and CRM systems, thanks to APIs. A more cohesive strategy for overseeing corporate operations is the outcome of this merger.
2. Enhanced Efficiency: APIs facilitate the automation of data transfer across systems, which eliminates the need for human data entry, minimizes errors, and boosts operational efficiency.
3. Innovation and Customization: Developers can expand Business Central's capabilities and create unique applications using APIs. This guarantees that companies may drive innovation in their operations and customize the solutions to meet their specific demands.
4. Automate Tasks: Simplify processes by allowing D365 Business Central to automatically transfer data to other programs, like payment gateways, CRM systems, and e-commerce platforms.
5. Acquire Insights in Real-Time: Create dashboards and reports using the most recent data from Business Central to get a thorough picture of your company's performance.
Standard APIs vs. Custom APIs
The Business Central API list includes two broad groups. Standard APIs are the ones Microsoft ships and maintains. They cover everyday records like sales orders, customers, vendors, items, and inventory. Custom APIs are API pages your developers build in AL when the standard ones do not expose what you need.
| Basis | Standard APIs | Custom APIs (built with AL) |
| Who maintains it? | Microsoft | Your partner or your developers |
| Typical data | Customers, vendors, items, sales and purchase documents, and G/L entries | Custom fields, industry tables, calculated values, extra business logic |
| Effort | Low. Call the endpoint. | Higher. Needs AL development, testing, and upgrade checks. |
| Upgrade risk | Low, versioned by Microsoft | Needs regression testing for each Business Central release wave. |
| Example use | Shopify order and customer sync, Dynamics 365 Sales account sync, posting to an external accounting tool | A freight app needing a custom shipment table, or a CRM needing a field your standard page does not expose |
| Choose when | The data you need is already in the standard entity. | You need fields, logic, or tables; the standard API does not expose |
Note: Start with the standard API. Move to a custom API only when you can name the specific field or process it cannot handle. We see companies build custom APIs for things the standard v2.0 entities already cover and then pay to maintain them every release wave.
How to use standard APIs
Standard APIs are plain REST endpoints, so any tool that can send an HTTPS request can use them: Postman, Power Automate, Azure Logic Apps, or code. For common apps you may not need to call them yourself.
You can visit Microsoft AppSource and search for a ready-made connector. Shopify is a good example: Business Central includes a built-in Shopify connector, so you set it up from within Business Central rather than writing API calls. Business Central and Shopify integration has a full walkthrough.
Standard APIs make life easier but have limits. If your process needs a field or a rule the connector does not handle, that is the point to look at a custom API.
Can You Extend Standard APIs?
Yes, in most cases, you can extend standard APIs by creating custom APIs. For example, you might need to expose additional business logic, retrieve additional fields, or integrate with a specific third-party application that Business Central doesn’t natively support. This is where custom API pages come in.
Custom API extensions can be built using AL code and integrated into Business Central. However, Microsoft's standard API pages are not extensible. Therefore, you should create separate custom API pages instead of modifying the base ones. This ensures better control and compatibility with future Business Central updates.
Business Central API integration examples for Canadian businesses
As we know, integration projects look different in Canada because tax, language, and data rules differ by province. These are the patterns we see most in Business Central Canada projects.
Shopify or WooCommerce to Business Central (retail, Toronto and Vancouver):
Online orders flow in as sales orders, customers sync both ways, and inventory levels go back to the store. The tax mapping is where it gets tricky. An order shipped to Ontario carries HST, while one shipped to British Columbia carries GST plus PST, and Quebec adds QST. If the integration does not map the ship-to province to the right tax area, your GST/HST return will not match what was collected. Our guide to sales tax setup in Business Central covers the Business Central side of that.
Dynamics 365 Sales (CRM) to Business Central (distribution, Calgary and Ontario):
Sales teams quote in CRM. Once an opportunity is won, the customer and the order move to Business Central. Finance stops asking sales for missing payment terms, and sales can see invoice status without emailing accounting.
Inventory sync across warehouses and 3PLs:
Stock quantities pushed to an external warehouse or marketplace prevent overselling during peak weeks. Polling every minute will hit throttling, so use filters or webhooks (see best practices below).
External accounting and reporting tools:
Posted G/L entries can feed a reporting tool or a parent company’s system. Keep an audit trail of what was sent and when. CRA generally expects businesses to keep records for six years, and a clean integration log makes a GST/HST review far less painful.
Note: Customer records often include personal information. If your integration moves that data between systems, PIPEDA applies to most private-sector businesses, and Quebec’s Law 25 adds further requirements for Quebec residents. Limit what each integration can read, which is another reason to scope Entra permissions tightly.
Security, best practices, and throttling for API Management in Business Central
When working with APIs in Business Central, consider these best practices:
Use the latest version: Use API v2.0 for new integrations.
Use OAuth 2.0: For Business Central Online, authenticate with Microsoft Entra ID and OAuth 2.0. The earlier advice about managing web service access keys for cloud setups has been removed. Basic authentication with access keys is deprecated for SaaS. On premises, prefer Entra/OAuth where you can and treat any remaining keys as secrets.
Manage permissions: Use a dedicated Entra app per integration and assign the smallest permission set in Business Central. If one integration is compromised, you want the damage limited to that one job.
Handle tokens and secrets carefully: Store client secrets in a vault such as Azure Key Vault, not in Postman collections shared by email or in code repositories. Set an expiry reminder so a secret does not lapse during month-end.
Version deliberately: Call a fixed version (api/v2.0) in the URL so a change on Microsoft’s side does not alter your integration unexpectedly. Review each releasewave’s notes.
Paginate: Large result sets come back in pages. Follow the @odata.nextLink value instead of assuming one response holds everything. Microsoft sets a maximum page size of 20,000 records for OData requests.
Respect throttling: Business Central Online returns HTTP 429 when request limits are exceeded. Retry with a back-off, filter with $filter (for example lastModifiedDateTime), use $expand to fetch related records in one call, batch operations (up to 100 per $batch request) and consider webhooks instead of polling. Requests that run longer than 10 minutes are aborted with a 504.
Handle errors properly: Log the status code and response body, retry only the errors that are worth retrying (429, 503, 504) and alert a person for the rest.
Test thoroughly: Use Postman or the VS Code REST Client against a sandbox environment before going live.
Keep customizations separate: Avoid altering standard Business Central pages when building custom API solutions. Create new custom API pages instead.
What Role Does Dynamics Square Play?
Dynamics Square is a trusted Microsoft Solution Partner in Ontario with 14+ years of experience. As a Business Central Partner in Canada, we help companies in Toronto, Vancouver, Calgary and across Canada connect Business Central to their CRM, e-commerce and accounting systems. That includes standard API integrations, custom AL-built APIs and fixing integrations that have started returning errors.
Expert consultation on whether you need a standard connector or a custom API
Implementation and configuration, including Entra ID, OAuth 2.0 and permission setup
Optimization and upgrades for integrations that break after a release wave
For more information, you can contact us via call atat +1 778 381 5388 or drop an email info@dynamicssquare.ca.
Frequently Asked Questions
An API in Business Central is a set of REST endpoints that lets external systems read and write Business Central data over HTTPS, which makes integration and automation possible.
To connect to an API in Business Central, you must enable API services using PowerShell commands, configure the API endpoints, and use tools like Postman to test the connection. Ensure your firewall allows communication through the default API service port (7048).
To enable APIs in Business Central, open the Business Central Administration Shell and run the following PowerShell commands:
Set-NAVServerConfiguration -ODataEnabled $true
Set-NAVServerConfiguration -EnableApiServices $true
After making these changes, restart your Business Central server to apply the settings.
Yes, Business Central offers open APIs, including REST APIs and SOAP Web Services, which allow developers to integrate with external systems and build custom solutions. You can explore the Business Central API list to check your required connector.
API v2.0 is the latest version and offers improvements over v1.0, including integration capabilities, system-managed fields, like “Created By” and “Modified By,” enhanced performance, and updated authentication methods. It is recommended that API v2.0 be used for new integrations.
You can refer to Business Central API Documentation to learn the technicalities of these API and identify the differences at the granular level.

