Category: API

Apr 08

OData Deprecation in Business Central: What Your Integration Architecture Needs Right Now

The Clock Is Ticking on Your OData Endpoints If you have integrations connecting to Business Central through OData web service endpoints, you need to start planning your migration today. Not next quarter. Not when v30 drops. Today. Microsoft has been signalling this move for years, but the concrete timeline is now clear. Version 30 (2027 Wave 1) will remove the ability to expose Microsoft-authored pages as OData endpoints entirely. Version 26 already shows warnings. Version 28 continues tightening. And SOAP endpoints? Those are being fully removed in version 29 (2026 Wave 2). This is not a minor API version bump. This is a fundamental shift in how Business Central expects external systems to communicate with it. And if you are running a multi-system architecture where BC is one node in a larger integration mesh, the impact goes well beyond swapping one URL for another. Why Microsoft Is Doing This (And Why They Are Right) The core argument is straightforward: UI pages were never designed to be APIs. They were designed for humans to interact with. When you expose a page like the Customer List as an OData endpoint, you are tying your integration to a contract that Microsoft never intended to be stable. Every time Microsoft updates the layout, adds a field, or restructures a page for user experience reasons, your integration is at risk of breaking. This has been a constant headache for years. Partners discover after an update that a field moved, a column disappeared from the default view, or a filter stopped working the way it used to. API Pages solve this by creating a purpose-built, versioned surface for programmatic access. They have explicit contracts. They are designed for throughput and filtering. They support proper versioning so that when Microsoft releases API v2.1, your v2.0 integrations keep working. From a design perspective, this separation between the human interface and the machine interface is exactly right. It just means a lot of work for everyone who took shortcuts. What Is Actually Changing: The Technical Timeline Let me break down the timeline with specifics: Version 26 (2025 Wave 1, already live): Warnings appear when you try to expose Microsoft UI pages as OData endpoints. SOAP endpoints for Microsoft pages are blocked by default. The telemetry signal RT0053 becomes available, which is your best friend for auditing what your tenants are actually calling. Version 28 (2026 Wave 1, current): Standard API surface continues to expand. New APIs arrive for sustainability, ESG reporting, and additional supply chain scenarios. OData deprecation warnings persist and become more prominent. Version 29 (2026 Wave 2): SOAP endpoints are fully removed. If anything still depends on SOAP, it will simply stop working. Version 30 (2027 Wave 1): OData support for Microsoft-authored pages is removed. Custom pages exposed as OData will still work, but Microsoft strongly recommends moving everything to API pages or API queries. There is also an important detail that often gets missed in discussions. Unbound Actions, which can currently only be called through OData (not the REST API), do not yet have a replacement in the REST API surface. This is a gap that Microsoft needs to address, and it is worth tracking closely. If your integrations use unbound actions on codeunits exposed through OData, you are in a particularly tricky spot. The Real Problem: It Is Not Just About Swapping URLs Most of the migration guides I have seen online focus on the mechanical steps. Find your OData endpoints, create equivalent API pages, update your connection strings. That is the easy part. The hard part is dealing with the knock-on effects: Different data shapes. API pages do not mirror UI pages. They expose a flatter, more predictable data structure. If your integration logic assumes the nested structure of an OData response from a page like the Sales Order, you will need to rethink your data mapping layer. Different filtering behaviour. API pages use OData v4 query parameters, but the available filter fields, supported operators, and response pagination differ from what you get when querying a UI page. Integrations that rely on complex filters need careful testing. Different authentication patterns. If you are moving from legacy OData with basic auth (still surprisingly common in on-prem to cloud migration scenarios), you will need proper OAuth 2.0 flows with Azure AD. This is a good thing, but it is also a significant change for some middleware setups. Rate limiting. The BC API enforces per-user limits of 6,000 OData requests per 5-minute sliding window, a maximum of 5 concurrent requests, and 100 simultaneous connections. If your integration was chatty against OData pages, you may need to rethink your request patterns. Missing API coverage. Not every entity that you can currently access through OData UI pages has a corresponding standard API. You will need to identify gaps early and plan to either build custom API pages or use API Queries for read-only scenarios. A Practical Migration Approach Here is how I would approach this in a real project, based on patterns I have used across integration implementations: Step 1: Audit Everything Before you write a single line of code, you need a complete inventory. Use the RT0053 telemetry signal in Application Insights to discover every external call hitting deprecated endpoints. This is not optional. You will be surprised at what you find. Middleware that someone set up three years ago and forgot about. A Power Automate flow that a functional consultant created. A reporting tool pulling data nightly. Run this across all your environments. Production, sandboxes, everything. If you do not have Application Insights configured, that is your actual first step. Step 2: Classify by Complexity Not all integrations are equal. Sort your discovered endpoints into three buckets: Simple swaps: The entity has a direct standard API equivalent. Customers, Vendors, Items, Sales Orders, Purchase Orders. These are relatively straightforward. Change the endpoint URL, adjust the data mapping, test, deploy. Custom API pages needed: The entity does not have a standard API, or your integration needs a specific data shape that the standard API does not provide. You will need to create custom API pages in a Per-Tenant Extension or AppSource app. Architectural rework required: The integration relies on patterns that do not translate directly. Unbound actions, complex multi-step operations that depend on page triggers, or scenarios where the integration was essentially screen-scraping a page through OData. Step 3: Design Your Custom API Pages Properly When you build custom API pages, do not just copy the structure of the UI page. Design the API for its actual consumers. Think about what fields the calling system actually needs. Think about the filters that will be applied. Think about whether an API Query would be better suited for read-only reporting scenarios. API Queries deserve special attention. They let you join data across tables and return exactly the shape your consumer needs, without the overhead of a full page object. For reporting integrations, data warehouse feeds, and analytics pipelines, API Queries are often the better choice. Step 4: Version From Day One One of the biggest advantages of API pages is versioning. Use it. Do not publish a custom API without a version number. When your requirements change (and they will), publish a new version alongside the old one. Give your consumers time to migrate. This is the discipline that UI pages as OData never gave you. The Unbound Actions Gap I want to call this out specifically because it is the one area where the migration story is incomplete. If you have integrations that call BC codeunits as unbound actions through OData, there is currently no REST API equivalent. Microsoft has not announced when or how this will be addressed. The practical options right now are: Wait and watch for Microsoft to fill this gap. This is risky if you are on a tight migration timeline. Wrap the logic in a custom API page with a bound action. This works for many scenarios but changes the calling pattern. Move the orchestration logic outside of BC entirely. Use Azure Functions or Logic Apps to coordinate the multi-step operations, calling individual API endpoints as needed. I lean toward option 3 for complex scenarios. It gives you more control, better error handling, and cleaner separation of concerns. But it is more work upfront. What This Means for Your Architecture If you are building new integrations today, the path is clear: use API pages, use the standard API v2.0, and design for the modern REST surface from the start. If you are maintaining existing integrations, start your audit immediately. Budget time for the migration in your 2026 and early 2027 planning cycles. Do not wait for the deadline. And if you are building middleware or integration platforms that connect BC to other systems, think about abstraction layers. Build your BC connector against the API surface with a clean mapping layer that isolates your business logic from the specifics of how BC exposes data. This way, when Microsoft eventually evolves the API further, your impact surface is contained. The deprecation of OData is not a crisis. It is Microsoft doing the right thing by separating the user experience from the machine interface. But it does require real effort, and the teams that start planning now will have a much smoother transition than those who wait until the warnings turn into errors.

Microsoft is removing OData support for first-party pages in Business Central v30 (2027 Wave 1), and SOAP endpoints disappear even sooner in v29. If your integrations rely on exposing UI pages as web services, the migration clock is already running. This post walks through the full deprecation timeline, explains why swapping URLs is only 20% of the work, covers the unbound actions gap that nobody is talking about, and lays out a practical four-step migration approach for teams managing multi-system architectures. Start planning now, not when the warnings turn into errors.

Feb 16

OAuth – Part 02 – Configure Service to Service Authentication

In this blog post, I’m going to take you through the steps required to complete the OAuth client credentials flow for Business Central. Check this link if you want to refer to the official post from Microsoft.

May 03

How to use a custom SystemId when inserting a record through an API

Have you tried to insert a record to Microsoft Dynamics 365 Business Central through a Custom API and pass a custom SystemId with the record?  Basically what I trying to achieve is when an Account is created in the D365 Sales system, I want to pass that record to D365 Business Central. I can easily …

Continue reading

Jul 14

Too many requests reached

What is the maximum number of API requests Microsoft Dynamics 365 Business Central can handle within a one minute?  Ran into this question a couple of months ago, specifically soon after the April release. Most of our Azure Logic Apps integrations to Microsoft Dynamics 365 Business Central started to fail due to API endpoint changes.  …

Continue reading

Jul 13

How to inject data to Customer Address Line 2 using Microsoft Business Central API

Creating a customer record in Microsoft Dynamics 365 Business Central is a topic I blogged about in one of my previous blog posts. If you have not read them yet I suggest you read it before going through this for better understanding.  Part 01: Getting Started with Dynamics 365 Business Central APIs Part 02: Understanding Microsoft Business …

Continue reading

Jul 13

Understanding Microsoft Business Central Custom API Endpoints

This is the third blog post about the Microsoft Business Central APIs and I suggest you go through below blog posts first if you haven’t read them yet. Part 01: Getting Started with Dynamics 365 Business Central APIs Part 02: Understanding Microsoft Business Central Out-Of-The-Box API Endpoints If you want to access custom developed API then this blog …

Continue reading

Jul 13

Understanding Microsoft Business Central Out-Of-The-Box API Endpoints

If you are working on a project which involves integrating a third party application to Microsoft Dynamics 365 Business Central, then I assume you have already come across with the Business Central APIs.  I noticed that most of the developers are still not comfortable with the endpoints of the BC APIs. Therefore this blog post …

Continue reading

Nov 04

Getting Started with Dynamics 365 Business Central APIs

API (Application Programming Interface) is an interface which allows applications to talk with each other. Simply put, it is more like a website, where you make a call to the server and you get a response from the server.  Dynamics 365 Business Central (D365BC) expose many “ready-to-use” APIs which allows seamless integration experience between other …

Continue reading