User-based service protection API limits in Microsoft Dynamics 365 Finance and Operations

Last month Microsoft announced user-based service protection API limits in Microsoft Dynamics 365 Finance and Operations. This information can be crucial for a project if there are many various integration flows implemented.

These limits are designed to preserve service health in the event of client applications with extraordinary demands on server resources. Additionally, these limits are designed to throttle incoming API requests when there are sudden bursts of traffic or concurrent long-running requests against the server.

The limits are designed to affect client applications that perform extraordinary API requests only, and protect against unexpected surges. Normally regular users of interactive clients and standard data integrations shouldn’t be affected. However, implemented OData and custom service integrations may require changes to handle the API limits. Requests that exceed the limits will return a 429 response with a Retry-After interval. So it may be required to make updates to optimize integrations, maximizing throughput.

The limits are in addition to the resource-based service protection API limits that have been in place for Finance and Operations apps environments since version 10.0.19 (which protects the environment from aggregated user demand exhausting environment resources). The user-based limits define specific API usage thresholds for OData and custom API (service) endpoints to prevent individual users or integrations from causing outages or degrading environment performance.

For now, the service protection API limits don't apply to all Microsoft services. The following services are currently exempt from them:

• Document Routing Agent (DRA)
• Warehouse Management mobile app (WHSMobile)
• Retail Server API
• Office Integration
• Data Import/Export Framework (DIXF)
• Data Integrator
• Dual-write
• Power Platform virtual tables for Finance and Operations apps
• Finance and Operations apps Connector

At this moment, according to the published documentation the new user-based service protection API limits will be available to enable in Finance and Operations apps environments with version 10.0.28 (PU53). In version 10.0.29 (PU54), with 2022 release wave 2, the API limits will be enabled by default in all environments. The limits will be optional, allowing environment administrators to temporarily disable them should additional time be needed to optimize integrations. In version 10.0.32 (PU56), with 2023 release wave 1, the API limits will be mandatory and the option to disable API limits will no longer be provided. So there is about one year to prepare for the new API limits.

The official documentation about the new feature can be found:

• Service protection API limits
• Throttling prioritization
• Retry operations
• Monitor API throttling
• Maximize API throughput

Note: The documentation is talking about "User-based" and not integration-based (app-id-based) but it seems "User-based" throttling is referring to the service principal, which is where the requests are being measured.

Also, here is a TechTalk video I find useful. This video can provide guidance and can answer some questions related to service protection API limits. 

In addition, I was able to find some topics related to the API limits which I found interesting, on the Internet. I wrote down the interesting points that I would like to share:

• If a generic user is used to run recurring batch jobs there is no option to opt this user out of the user-based service protection API limits so far.
• OData requests with $batch (like exchange rates) will be subject to the same throttling limits. It may be needed to adjust the number of records included in the batch to not exceed any of the three usage limits.
• An example of "execution time" for throttling:

There are 6000 oData calls per 5 minutes and each call takes 1 second to execute. 

Because of "Execution time" limits (20 minutes (1,200 seconds)) in this scenario number of calls  will be limited to 1200 since the limit is on the cumulative execution time of the API requests for that user/service principal within the 5-minute sliding window. So the number of API requests that can be made, will be limited by how compute-intensive the requests are.