Last updated: November 10, 2026
By ZapAI Team
The Business Central API is how outside systems read and write data in Microsoft Dynamics 365 Business Central online, from web stores and CRMs to warehouses, banks, payroll providers and data platforms. As of November 2026 the safe default is the standard API v2.0 or a custom API page, called through a Microsoft Entra app registration that runs without a signed-in user, which is how Microsoft expects unattended integrations to work. SOAP on Microsoft pages is gone. OData on Microsoft UI pages goes next.
The Business Central API is a versioned OData v4 REST interface. Use standard API v2.0 endpoints or custom API pages, authenticate with Microsoft Entra service-to-service OAuth, receive changes through webhooks, and design around per-user throttling limits from the first sprint.
Most integration guides list endpoints and stop. That’s the easy part. The questions that cost money show up later, when an order sync throws 429 errors on a Monday morning, a webhook subscription quietly expires, or a vendor’s connector turns out to call a UI page Microsoft is about to stop exposing.
This guide covers endpoint options and deprecations, authentication, limits, webhooks and events, batching, Power Automate and Azure, Dataverse and agents, a pattern table, testing, failure points and a checklist. Every product fact was checked against Microsoft Learn on November 10, 2026, with Business Central on version 29.
What Is the Business Central API, and Which Endpoint Should You Use?
It’s a family of endpoints, not one thing. For new work, use standard API v2.0 when it already exposes what you need, and a custom API page when it doesn’t. Everything else is legacy or a special case.
| Option | Status, November 2026 | Use it for |
|---|---|---|
| Standard API v2.0 | Current, on by default online | Customers, vendors, items, sales and purchase documents, journals |
| Custom API pages and API queries | Current, built in an AL extension | Fields or tables the standard API lacks, read-only joins |
| OData on Microsoft UI pages | Removal set for version 30, 2027 release wave 1 | Nothing new. Plan the exit. |
| SOAP on Microsoft UI pages | Removed in version 29.0 | Nothing. Already gone. |
| API v1.0 | Removed in update 28.0 | Nothing. Move to v2.0. |
| Business Central MCP server | Available online, some tools in preview | AI agents acting under a user’s identity |
| Power Automate connector | Premium connector | Alerts, approvals, light syncs |
Standard APIs live under the api/v2.0 path, and every resource sits inside a company, so the company ID appears in nearly every call your integration makes, from a customer lookup to a posted invoice download. Custom API pages add their own publisher, group and version to the path, and both kinds speak OData v4 with filtering, expanding and webhooks.
One rule catches developers early. You can’t extend a standard API page. Microsoft’s API v2.0 reference says to copy the AL code and build a custom API instead.
Why not just publish a UI page? Stability. A UI page can change in any monthly update without Microsoft calling it a breaking change, while API pages are versioned contracts built for integration, and that single difference explains nearly every deprecation in the next section.
What Happened to SOAP, OData UI Pages and API v1.0?
Three older paths are closing. API v1.0 was removed in update 28.0. SOAP on Microsoft pages ended in version 29.0. OData on Microsoft pages ends in version 30.
Microsoft’s deprecated features list for the platform spells out the OData change. Starting in version 30, no page from an app published by Microsoft can be exposed as an OData endpoint, which covers the Base Application, the System Application and every first-party app. Need one anyway? Copy the page into your own extension.
Read the SOAP wording carefully. The version 29 removal targets Microsoft pages, and version 29 made the feature that disables SOAP on those pages mandatory. An older entry says SOAP endpoints in general will be removed in a future release, with no version named. Some vendor blogs claim every SOAP call died in version 29. The Microsoft pages we checked don’t say that. Either way, SOAP is a dead end.
API v1.0 is simpler. Microsoft’s deprecated features list for the application marks it removed in update 28.0 and says v2.0 holds all its functionality. Keys became SystemId GUIDs. Nested addresses became flat fields. So payload mapping changes too.
Our advice is to inventory every service on the Web Services page now. Flag anything that points at a Microsoft UI page. Then ask every connector vendor, in writing, which endpoints they call.
How Does Authentication Work for Business Central APIs?
Business Central online accepts OAuth through Microsoft Entra ID only. For unattended integrations, use service-to-service authentication, the OAuth client credentials flow, with an app registration holding the API.ReadWrite.All application permission and a matching record inside Business Central.
Basic authentication is long gone online. Web service access keys stopped working for Business Central online after October 1, 2022, per the platform deprecation list. On-premises can still use them. Cloud can’t.
Setup has two halves, according to Microsoft’s service-to-service authentication guide.
- Register an app in the Microsoft Entra admin center and create a secret or certificate.
- Grant the Dynamics 365 Business Central application permission API.ReadWrite.All, plus Automation.ReadWrite.All only for automation APIs.
- Grant admin consent.
- In Business Central, open Microsoft Entra Applications, enter the client ID, set the state to Enabled and assign permission sets.
- Test with one company.
Permissions are where shortcuts happen. Microsoft blocks the SUPER permission set for applications and asks for least privilege, so build a permission set per integration that covers only the tables, pages and actions that one integration actually touches. A web store connector that reads items and writes sales orders has no business posting journals.
There’s a cost upside too. Microsoft’s guide to OAuth for Business Central web services compares both approaches. A user account must be licensed. An application account doesn’t need a license. And delegated flows can be blocked by multifactor prompts.
Two rules from our projects. Give each integration its own app registration, so you can revoke one without breaking the rest. And give secret expiry dates a named owner, because an expired client secret looks exactly like an outage.
What Limits Will Your Integration Hit?
Per user, Business Central online allows 6,000 OData requests in a five-minute sliding window, five processing at once and 100 open connections. Per environment, pages cap at 20,000 entities, a $batch holds 100 operations and requests time out after 8 minutes.
| Limit | Value | Result when exceeded |
|---|---|---|
| Request rate, per user | 6,000 per 5-minute sliding window | HTTP 429 |
| Concurrent requests, per user | 5 | Queued, then 503 after 8 minutes |
| Max connections, per user | 100, processing plus queued | HTTP 429 |
| Request queue, per user | 95 | HTTP 429 |
| Max page size | 20,000 entities | HTTP 413 |
| Max $batch size | 100 operations | Request rejected |
| Max request body | 350 MB | Request rejected |
| Operation timeout | 8 minutes | HTTP 408, session canceled |
| Webhook subscriptions, per environment | 200 | No new subscriptions |
Values come from Microsoft’s operational limits for Business Central online, checked November 10, 2026.
Two Microsoft pages disagree on timeouts. The limits page says 8 minutes and HTTP 408. Microsoft’s API limits guidance, last updated in 2024, says 10 minutes and HTTP 504. Design for 8. Handle both codes.
Here’s the limit that bites SMBs. Microsoft applies these limits to application users exactly as it does to people, and says more users mean more throughput, so a single service principal running every integration you own gets one user’s capacity, which is five requests at a time no matter how big your company is. A web store sync, a 3PL feed and a nightly reporting extract sharing one app registration will throttle each other. Usually at month end.
What we do about it.
- One app registration per integration
- Exponential backoff with jitter on 429 and 503. Microsoft asks for a cool-off period, not instant retries.
- Filters and next-page links instead of giant reads
- $expand for headers with lines, deep inserts for creates
- Push, not poll.
Should You Poll, Use Webhooks or Use Business Events?
Use webhooks when an outside system needs to know a record changed. Use timestamp polling for bulk and analytics extracts. Use business events when a business moment matters, like an invoice posting, and accept that they’re still a preview.
Webhooks
Webhooks push a notification when a subscribed resource changes. Microsoft’s webhooks guide sets the rules.
- Your endpoint must echo a validation token with HTTP 200 to register.
- Subscriptions expire after three days. Renew with a PATCH.
- Notifications wait 30 seconds after the first change.
- Over 1,000 changes in that window become one collection notification.
- Failed deliveries retry for 36 hours, but only after a 408, 429 or 5xx reply.
- Any other error code deletes the subscription.
Read that last bullet twice. If your receiving endpoint returns a 404 during a deployment, Business Central drops the subscription and stops sending, and nothing alerts you until a customer asks why the store still shows last week’s stock. We run a daily job that lists subscriptions, renews anything near expiry and recreates anything missing.
Notifications are thin. They carry the resource path, change type and timestamp, so your handler fetches the record afterward. One extra GET each. Use the optional clientState value as a shared secret.
Coverage has gaps. Standard resources include customers, vendors, items, sales orders, sales invoices, purchase invoices and journals, among others. Custom API pages fire webhooks too, unless they sit on temporary or system tables, use composite keys, or are API queries.
Polling and delta loads
Delta links were deprecated in versions 23 and 24. For bulk extracts, Microsoft’s guide to extracting data from Business Central, updated November 6, 2026, describes filtering and ordering on lastModifiedDateTime, which maps to SystemModifiedAt, and sending reads to a read-only replica through the Data-Access-Intent header or the DataAccessIntent property.
Deletes are the catch. Microsoft says timestamp filtering finds added and modified records but not deleted ones. Pair it with webhooks, which do report deletes, or with a periodic comparison of record IDs between the two systems, run weekly or nightly depending on how fast stale records hurt you.
Business events
Business events tell Dataverse or other systems that something happened, like a sales invoice posted, a purchase order released, a customer blocked or a credit limit exceeded. Microsoft’s business events overview still labels them a preview, with setup through the Dataverse connection and the Virtual Table app.
We like events for process triggers. A posted shipment means more to a 3PL than ten line edits. But previews carry no production promise, so we keep a webhook or polling fallback behind anything that moves money or stock, and we revisit that choice each time Microsoft updates the feature’s status.
When Do $batch and Deep Inserts Help?
Use $batch when one business operation spans several requests that must succeed or fail together, like a payroll journal. Use deep inserts to create a header and its lines in one call. Both save requests.
A $batch bundles up to 100 operations into one HTTP call. Add an Isolation header set to snapshot and it turns transactional, per Microsoft’s guide to OData transactional batch requests. One failure rolls back the whole batch. Unless AL code commits partway.
That exception matters. Some Business Central logic commits on its own, posting routines in particular, so a transactional batch wrapped around a posting call won’t fully roll back, and you only find that out when a half-posted payroll run lands in the general ledger. Test the exact sequence in a sandbox. Every time.
Deep inserts are the quieter win. A POST to sales orders can carry its lines nested in the body, turning a header plus 40 line calls into one request, which matters more than it sounds when five concurrent requests per user is the ceiling you’re working under. Pair it with $expand on reads.
Watch the clock. A batch running past 8 minutes fails as a unit. We size batches by measured run time, not by the ceiling.
Where Do Power Automate, Logic Apps and Azure Integration Services Fit?
Power Automate suits alerts, approvals and low-volume syncs owned by business users. Azure Logic Apps, Functions, Service Bus and API Management suit high-volume integrations owned by IT. The connector’s authentication limits push serious integrations toward Azure.
Microsoft’s Business Central connector reference lists record triggers, approval triggers, a business event trigger in preview, record actions and MCP actions. It’s premium in Power Automate. Throttling sits at 300 API calls per connection every 60 seconds. Records must stay under 8 MB.
Then comes the limitation that changes architecture. Per Microsoft’s Power Automate integration overview, the connector doesn’t support service-to-service, service principal or managed identity authentication in Power Automate, Logic Apps, Copilot Studio or Power Apps. Flows run under a person’s connection. Person leaves, flows break. Microsoft points app-only scenarios to the OData connector for now.
Our rule of thumb is simple. If a flow stopping would stop the business, it shouldn’t hang on one employee’s sign-in. Approvals and Teams alerts fit Power Automate, and our Power Automate use cases roundup shows where flows pay off. Order, inventory and payment syncs belong in Azure, ideally with our Power Automate services team handling the flow side next to your Azure developers.
On Azure, the patterns aren’t Business Central specific. Queue inbound orders in Service Bus so a throttled ERP doesn’t drop them, call the API from a Function or Logic App with backoff, and put API Management in front when partners call you. Our guides to Azure integration patterns, Logic Apps vs Azure Functions and API Management best practices cover those building blocks.
What About Dataverse, Fabric and AI Agents?
For Dynamics 365 Sales, use the built-in Dataverse integration. For analytics, look at Fabric mirroring, still a preview, or API queries. For AI agents, Business Central has its own MCP server working through API pages under the signed-in user.
Dataverse first. The standard sync with Dynamics 365 Sales already moves customers, items, prices and orders, so rebuilding it on raw APIs repeats Microsoft’s work. Our Business Central and Dynamics 365 Sales integration guide covers that path. No need to rebuild it.
Data platforms next. Microsoft’s extraction guide describes a Fabric mirroring app, labeled a preview, that copies selected companies and up to 1,000 tables into OneLake with an initial snapshot plus incremental changes. If Fabric is the target, that beats a hand-built pipeline on upkeep. Otherwise, use API queries with read-only intent. Our Fabric data engineering team builds both.
Then agents. The Business Central MCP server overview describes one endpoint at mcp.businesscentral.dynamics.com that, by default, lets an agent discover and read the API pages and API queries the signed-in user can access, while admins switch on create, modify, delete and action tools per configuration. It authenticates with the OAuth authorization code flow plus PKCE. So every action runs as a real user. Not an app. Audit trails stay honest.
Status needs care. Version 29 release notes call MCP data queries generally available, yet the configuration page still labels Data Query Tools a preview. Custom API pages become agent tools as well, described by their AboutText property. For the Dataverse version of this idea, see our Dataverse MCP server guide. Built-in agents are a separate feature, covered in our Business Central agents guide.
Which Integration Pattern Fits Your Scenario?
Match the pattern to volume, ownership and the cost of a missed message. This table is how we open design conversations. It’s ZapAI practice, not Microsoft guidance.
| Scenario | Pattern we’d start with | Watch out for |
|---|---|---|
| Shopify store | Microsoft’s built-in Shopify connector | Version 29 added B2B, refunds and order changes. Check before building custom. |
| Other e-commerce platforms | Orders queued in Service Bus, sales orders by deep insert, webhooks on items back to the store | Peak throttling, duplicate orders on retry |
| Dynamics 365 Sales | Built-in Dataverse integration | Field ownership, skipped records |
| Salesforce or HubSpot | Middleware with webhooks on customers and items, custom API for extra fields | Who owns addresses and credit status |
| WMS or 3PL | Custom API pages for shipments and receipts, webhooks or events for released documents | Partial shipments, posting that commits mid-batch |
| Banking and payments | A Marketplace banking app first, custom API into payment journals second | Segregation of duties |
| Payroll | Transactional $batch into a general journal, posted by a person | Batch size against the 8-minute timeout |
| Data warehouse or Fabric | Fabric mirroring when Fabric is the target, otherwise API queries with read-only intent | Deletes missed by timestamp filters |
| Approvals and alerts | Power Automate connector | Connections tied to one person |
| AI assistants | Business Central MCP server with a curated configuration | Write tools enabled too broadly |
Banking and payroll touch money. Our view is that those integrations should land data in a journal and stop. A person posts. Always.
Bigger estates change the math. Once five or more systems talk to Business Central, a central integration layer usually beats a tangle of point-to-point connectors, which our guide to Azure integration for enterprises treats in detail.
How Should You Test and Monitor a Business Central Integration?
Build and load-test in a sandbox, then watch production through telemetry in Azure Application Insights. Premium and Essentials subscriptions include three sandbox environments at no extra charge, per Microsoft’s environment documentation, so there’s rarely a good reason to test a new integration against the production company your accountants close the books in.
Sandboxes copied from production behave differently on purpose. Microsoft’s environment documentation says a copy disables all webhooks and several service connections, and blocks outbound HTTP calls from extensions until someone turns on Allow HttpClient Requests for each one. Safety feature. Also the reason somebody swears it worked yesterday.
Tests that pay off.
- A load test at real peak volume
- Forced throttling. Confirm the client backs off.
- A failed handler mid-delivery, then proof the subscription survived
- Duplicate deliveries, ignored by the handler
- A batch failing halfway
- Expired secrets.
For monitoring, environment telemetry flows to an Application Insights resource you own. Microsoft’s web service request telemetry records each incoming API, OData and SOAP call with its endpoint, duration, HTTP status and the AL object it ran, and a separate trace covers outgoing calls. Alert on 429 counts and failures per app registration. Rising 429s are your earliest warning.
Where Do Business Central Integrations Usually Break?
In our experience, five causes. Shared credentials, expired webhook subscriptions, UI pages used as APIs, missing retry logic and deletes nobody synced.
| Symptom | Likely cause | Fix |
|---|---|---|
| 429 errors at month end | Several integrations on one app registration | Separate registrations, backoff, fewer calls |
| Store stops getting stock updates | Webhook subscription expired or deleted after a 4xx reply | Daily renewal and health job |
| Breaks after a monthly update | Calls a published UI page | Rebuild on API pages |
| HTTP 413 on a large read | Over 20,000 entities | Filters and server-driven paging |
| 408 or 504 on big jobs | Long-running request | Smaller batches, API queries, read-only intent |
| Deleted items still live in the store | Timestamp polling can’t see deletes | Webhooks or key reconciliation |
| Flows fail after an employee leaves | Connector bound to a personal connection | Move critical syncs to Azure |
| Nothing works in a new sandbox | Copy disabled webhooks and outbound HTTP | Re-register, allow HttpClient requests |
Vendors deserve scrutiny. Before you sign, ask which endpoints a connector calls, whether it uses its own app registration or a shared user, how it handles 429s and what happens to its webhooks after a sandbox copy. Vague answers are an answer.
What Belongs on Your Integration Checklist?
Inventory endpoints, pick a pattern per system, create one least-privilege app registration per integration, build retries and subscription renewal, test at real volume, then monitor. That’s ZapAI’s working order.
Design
- Published web services listed, UI pages flagged
- Pattern chosen per system
- Field ownership agreed
- Standard API checked first
- Money flows end in journals.
Build
- One Entra app registration per integration
- Least-privilege permission set. Never SUPER. No exceptions.
- Backoff on 429 and 503
- Webhook renewal job
- Idempotent handlers. Retries happen.
Run
- Telemetry in Application Insights
- Throttling alerts on
- Secret expiry owned
- Deprecation notices reviewed quarterly
Mid-project? Our Business Central implementation guide explains why integrations tested late are a leading reason go-lives slip.
What Could Change After Ignite 2026?
Possibly a few things. Ignite runs November 17 to 20, 2026, in San Francisco. Treat this post’s preview labels, MCP details and connector limits as a snapshot, and expect a refresh by late November.
We’ll check whether business events reach general availability, whether the Power Automate connector gains service principal support, how the MCP server’s preview tools move, and whether Fabric mirroring leaves preview. The version 30 OData removal is already scheduled. Don’t wait on Ignite to start that work. Start now.
Wrapping Up
Good Business Central integrations look boring. API pages, one app registration per integration, webhooks with a renewal job, retries that back off, and telemetry somebody reads. Risky ones lean on UI pages, share one service account and assume the API never says no. Fix those before version 30 forces it.
ZapAI is a Microsoft Dynamics 365, Power Platform, Fabric and AI consulting firm in Irving, Texas, working with businesses across Dallas-Fort Worth and nationwide. Our Business Central consultants design API integrations, build custom API pages, move legacy SOAP and OData connections onto supported endpoints, and set up monitoring. Talk to us about your Business Central integrations, and we’ll review your endpoints, credentials and limits before anything breaks.
Questions Teams Ask About the Business Central API
Is the Business Central API free to use?
Microsoft publishes no per-call charge on the pages we checked, and an application account used for service-to-service authentication needs no Business Central license. Calls still count against operational limits, and Power Automate’s premium connector carries its own licensing.
What is the rate limit for the Business Central API?
Per user, 6,000 OData requests in a five-minute sliding window, five processing at once and 100 open connections. Exceeding them returns HTTP 429. Application users get the same limits as people.
Does Business Central still support SOAP web services?
Not for Microsoft pages. Publishing Microsoft pages as SOAP endpoints ended in version 29.0, and Microsoft says SOAP endpoints in general will be removed in a future release. Build new integrations on API pages.
Can I still publish a Business Central page as an OData web service?
Until version 30, yes. From the 2027 release wave 1, pages from apps published by Microsoft can’t be exposed as OData endpoints. Your own extension pages aren’t affected.
Does Business Central support webhooks?
It does, for standard API v2.0 resources and most custom API pages. Subscriptions expire after three days unless renewed, and a subscription is deleted if your endpoint returns an error code other than 408, 429 or 5xx.
How do I get only changed records from the Business Central API?
Filter and order on lastModifiedDateTime, since delta links were deprecated. That finds new and changed records but not deleted ones, so combine it with webhooks or a periodic key check.
Can Power Automate connect to Business Central with a service principal?
Not through the Business Central connector today. Microsoft says it doesn’t support service-to-service, service principal or managed identity authentication, so flows run under a user’s connection. App-only scenarios use the OData connector or Azure services instead.