Running a large enterprise ERP raises different questions when connecting a shop than running a lean inventory system does. Dynamics 365 Finance, Microsoft's extensive Finance and Operations system, is deliberately distinct from Business Central: more data volume, stricter governance and its own integration model. Two paths move data back and forth between Finance and the online shop, namely OData entities for real time and individual records, and the Data Management Framework (DMF) for bulk data and data packages. The 2026 release wave 1 rolls out from April to September 2026 (Microsoft Learn) and further expands exactly these integration building blocks. This article shows how to synchronize items, prices and orders cleanly, when OData and when DMF is the right path, and how to handle the system's API limits so a bulk import does not slow down day-to-day operations.
Key takeaways
- Dynamics 365 Finance (Finance and Operations) is not Business Central: higher data volume, multi-company support and its own integration model. Two transport paths — OData for real time, DMF for bulk data — together cover items, prices and orders.
- OData entities deliver individual records synchronously, but are capped at 6,000 requests per 300 seconds (Microsoft Learn) per tenant; beyond that the service responds with the HTTP 429 status code.
- The Data Management Framework bundles large volumes into data packages and recurring integrations and is the right path for the initial catalogue load and for nightly full reconciliations.
- Service protection limits of 6,000 requests per 300 seconds (Microsoft Learn) and priority-based throttling protect the service; integrations can be classified as high, medium or low (Microsoft Learn).
- Business events and change tracking replace constant polling: Finance reports changes instead of the shop polling non-stop. This eases the API limits and keeps stock current.
Dynamics 365 Finance Is Not Business Central
Microsoft runs two very different ERP worlds under the Dynamics 365 brand. Business Central targets small and mid-sized companies and offers a lean, well-documented REST API; connecting that system is described in the article on connecting Business Central to the shop. Dynamics 365 Finance, often called Finance and Operations or F&O for short, plays in a different league. It manages group structures with several companies, complex trade agreements and data volumes that quickly push individual requests to their limits. Confusing the two systems means planning the wrong architecture: what is a simple API call in Business Central demands a deliberate choice between synchronous OData and package-based data import in Finance.
The economic backdrop is familiar: 61 percent (Bitkom, Digitalisation of the Economy 2025) of companies cannot fully exploit their data potential because information sits in unconnected systems. In F&O landscapes this effect is especially costly because so many data types converge there. A clean link between Finance and shop therefore decides whether the shop shows reliable availability and prices or whether things are permanently patched up by hand in the background. How much technical discipline this requires is already clear from the comparison with other enterprise systems such as SAP, which impose similar governance demands.
OData Entities as the Real-Time Door to the Shop
OData is the synchronous gateway to Finance. The system exposes so-called data entities, that is, functionally grouped views on tables that are accessible through a REST-like endpoint. A call returns individual records in JSON format and supports query parameters such as $filter and $select, which let you narrow the transferred data on purpose. Because F&O knows several companies, every call must address the correct legal entity, either through the cross-company parameter or through the fixed context of the integration user. For connecting a shop, OData is the right path for everything that has to be current and singular: an order handover, a price query, a status update.
OData's limit lies in volume. Every record is a separate request, and the number of requests is capped. If the shop polls entire catalogues over OData non-stop, it inevitably runs into throttling. That is why OData belongs where few, current records matter, and not where tens of thousands of items are moved at once. Whether the connection should run directly or through an intermediate layer is set out in the article on the question of REST API or middleware. In practice, a dedicated integration layer or API development handles the translation between the OData entities of Finance and the data model of the shop.
The Data Management Framework for Bulk Data
For large data volumes, the right path is not OData but the Data Management Framework. In DMF, data entities are bundled into data projects that process whole record sets as an import or export package in formats such as CSV or XML. This is the right technique for the initial load of a shop catalogue, for nightly full reconciliations or for handing over extensive price lists. Through so-called recurring integrations, these packages can be enqueued and dequeued in a scheduled and automated way over HTTPS, with a mechanism that makes the state of every package traceable.
The price of this power is system load. DMF exports run as batch jobs and can significantly burden the database server if they start at the wrong time or too often. That is why large reconciliations belong in low-load time windows and need deliberate planning. How to stagger bulk imports without breaking the limits of the cloud platform is covered in detail in the article on cloud ERP API limits and bulk imports. For consolidating several systems beyond the shop alone, a middleware as a central hub is often sensible as well.
OData Entities
Synchronous access to individual records in JSON format, with $filter and $select for targeted queries.
Data Management Framework
Data packages and import or export projects for bulk data such as catalogue, prices and initial load.
Recurring Integrations
Scheduled, automated package handover over HTTPS with an enqueue and dequeue mechanism.
Business Events
Finance actively reports events to an endpoint instead of being polled by the shop.
Change Tracking
Only changed records are transferred, which keeps delta reconciliations lean and fast.
Custom Services
Your own business logic as a dedicated endpoint when standard entities are not enough.
OData or DMF: Which Path When
The most important decision in every F&O integration is choosing the transport path per data type. Rule of thumb: everything current and singular goes over OData; everything large and scheduled goes over DMF. An order handover right after purchase belongs to OData because it should arrive immediately. The nightly reconciliation of 40,000 items belongs to DMF because it runs more efficiently and gently as a package. Many projects combine both paths: DMF for the base load, OData for the real-time events on top.
| Criterion | OData Entities | Data Management Framework |
|---|---|---|
| Data volume | Single to a few records | Large volumes and full reconciliations |
| Timeliness | Real time, synchronous | Batch, scheduled or triggered |
| Typical use | Order, price query, status update | Catalogue first load, nightly reconciliation |
| Format | JSON per record | Data packages such as CSV or XML per project |
| Limit | Service protection limits per request | Resource load on the batch server |
| Error picture | HTTP status per call | Execution log per data project |
Synchronizing Items, Prices and Orders Cleanly
A reliable integration separates the data types and defines the leading system for each. For items, prices and stock this is usually Finance, for orders initially the shop, which then hands the orders over to Finance. What matters is a clean field mapping between the shop data model and the F&O entities so that number ranges, units and tax codes line up at both ends. How such a field mapping is built methodically is described in the article on data mapping between ERP and shop.
- Items and master data: Initial load via a DMF data project, then only OData deltas on change. Number ranges, units and categories belong firmly in the mapping.
- Prices and trade agreements: Finance is leading. Price lists and customer-specific terms flow into the shop, not the other way around, so that one price truth remains in the inventory system.
- Stock: Warehouse or site-level availability is aggregated. Critical items by event, the rest of the catalogue by a short delta sync.
- Orders: The shop hands orders over via OData as a sales order to Finance; order status and shipping information flow back into the customer account.
- Documents and invoices: Invoices and credit notes originate in Finance. The e-invoice under XRechnung and ZUGFeRD is treated as a separate process because it follows stricter format rules.
As soon as data flows in both directions, the same record can be changed in two places at once. For this case you need clear rules on which system wins in a conflict. How to resolve such collisions without losing data is shown in the article on bidirectional synchronization and conflict resolution.
Mastering API Limits and Throttling
Finance protects itself against overload, and it does so on several levels. From version 10.0.19, the service protection limits allow 6,000 requests per 300 seconds (Microsoft Learn) per environment and additionally cap the combined execution time at 1,200 seconds per 300 seconds (Microsoft Learn). In parallel, priority-based throttling caps OData requests at 6,000 per 300 seconds (Microsoft Learn) per tenant. When a limit is exceeded, the service responds with HTTP 429 and a Retry-After hint that states how long the caller should wait. The earlier user-based limits have not been enforced since March 31, 2023 (Microsoft Learn).
The actual trick lies in prioritization. Administrators classify every integration as high, medium or low. When the web server utilization reaches 60 percent (Microsoft Learn) of CPU or memory, low-priority requests are asked to retry first; from 70 percent (Microsoft Learn) it also hits the medium tier. This keeps the interactive user working while a non-critical background integration waits briefly. Anyone who classifies their calls accordingly and reacts to HTTP 429 with a clean retry mechanism does not run into a wall. The matching idempotency and retry strategies ensure that a retry does not create an order twice.
Respond to HTTP 429 Correctly
Business Events Instead of Polling
The gentlest way to ease the API limits is not to poll non-stop in the first place. Finance can actively report through business events when something happens, such as a posted document or a changed price list. The shop or the middleware then reacts in a targeted way instead of checking at short intervals whether anything has changed. Combined with change tracking, which marks only the records that actually changed, this creates an event-driven flow that drastically reduces the number of requests. When this approach pays off compared with classic polling is weighed up in the article webhooks versus polling.
Secure Connection and Permissions
Access to Finance runs through Microsoft Entra ID. The integration registers there as an application and authenticates via the OAuth 2.0 client credentials flow before it may use OData or DMF. In F&O, this application is assigned its own integration user whose permissions are kept deliberately narrow: only the entities and operations the connection really needs. This principle of least privilege keeps the damage small if an access token ever falls into the wrong hands. An instructive comparison is the token-based sign-in of other enterprise systems, for example through the Service Layer of SAP Business One, which follows a similar logic.
Implementation Step by Step
- Clarify data types and leading systems: Define which data type comes from Finance and which from the shop, and document the field mapping.
- Choose the transport path per data type: OData for real-time single records, DMF for bulk data and initial load, combined where needed.
- Set up access: Register the application in Microsoft Entra ID, create an integration user in F&O with minimal rights, enable the entities.
- Plan for throttling: Prioritize integrations, implement retry behaviour on HTTP 429, place bulk runs in low-load time windows.
- Test and go live: Run through order handover, full import and peak loads in a test environment, then go live with close monitoring.
Two Paths, One Data Truth
Not every connection needs real time, and not every bulk load belongs in a single request. The art of the F&O integration is choosing the right path per data type.