Today, we delve into service protection API limits within the Dynamics 365 Finance and Operations apps. These limits, particularly implemented for Odata and custom service endpoints, serve a pivotal role in maintaining consistent service standards.
We will touch on the essence of the limits as well as how to mitigate strategies to achieve optimal throughput via API integrations.
Service Protection API Limits
The creation of service protection limits stems from a need for sustained availability, reliability, and performance of the Finance and Operations service. They act as a buffer against excessive API usage, which might otherwise degrade service performance or cause temporary service outages.
Internally, our dedicated team of service engineers continually monitors performance, service availability, and adherence to our uptime and service level agreements.
Types of Limits
There are chiefly two categories:
Resource-based Limits: These are contingent on the cumulative usage of service and database resources. Should there be any potential threat to service performance or availability due to excessive usage across all API users, throttling mechanisms are triggered.
User-based Limits: Aimed at safeguarding the environment from any single user or integration that might unduly burden the system. These are enforced per user or service principle on each web server.
Integration Types & Their Considerations
Interactive Clients: These involve multiple users authenticating with their unique credentials. Owing to the distributed nature of requests, hitting the API limits is less frequent.
Anonymous Users: Here, unauthenticated users interact with the application, leading to a single service principle catering to all API calls.
Data Integrations: Often involving bulk data operations, it’s paramount to consider techniques like batching to ensure even distribution of workload.
Handling a 429 Response
For interactive applications, employ the ‘Retry-After’ logic. In the event of a 429 response due to a surge in requests, notify the user about server busyness and discourage further requests till the previous ones are processed. For non-interactive applications, observe the ‘Retry-After’ duration before resending the request.
Maximizing API Throughput
While there isn’t a one-size-fits-all strategy, considering the diversity of integrations, a few generic recommendations can guide the process:
- Monitor API throttling via reports in lifecycle services (LCS).
- Allow the server to dictate retry timings through the ‘Retry-After’ interval.
- Employ multiple threads for quicker individual operations.
- Distribute workloads among various service principles.
- Keep batch operations within the 5k limit.
- Ditch the affinity cookie for better request routing.
- Optimize connections for improved throughput.
Temporary Exemptions from API Limits
Certain third-party and Microsoft services enjoy temporary exemptions:
- Document Routing Agent
- 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.