Share
Report
22The documented API limits (https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/administration/operational-limits-online) state that OData rate limits (5 concurrent requests, 100 connections, 95 queued, 6,000 requests/5-min) were moved from per-environment to per-user/per-service-principal, specifically to increase achievable throughput when spreading load across multiple integrations.
My question: if I distribute load across N separate service principals/app registrations, does the effective total capacity scale linearly with N (i.e., N × 100 connections, N × 95 queued, etc.), or is there some additional environment/tenant-level aggregate ceiling that kicks in once combined load across all principals gets high enough — regardless of how it's distributed?
Since Business Central runs on shared infrastructure per environment, it seems plausible that even with per-user quotas, there could be a "noisy neighbor" style aggregate cap sitting above the sum of individual per-user limits (similar to how Microsoft Graph's documentation explicitly describes a "per tenant, for all apps" tier above the per-app quota) — but I haven't found this addressed anywhere in the Business Central docs.
Specific questions:
1. Is there an official aggregate/environment-level ceiling above the sum of per-user limits? If so, is it documented, and does it scale with tenant size/licensing (similar to how sandbox vs. production speed limits differ)?
2. Does adding more users/service principals to a tenant increase this shared ceiling (as hinted at in the per-user limits FAQ regarding scaling resources), or is it a fixed platform-side cap?
3. Is there any way to monitor or query current headroom against this ceiling (e.g., via telemetry/Application Insights), rather than only discovering it via 429 responses during production load?
Any insight from Microsoft or others who've tested multi-integration throughput at scale would be appreciated.
All responses (
Answers (
