Forum Discussion
API Call Limit for F SKUs
Hi fabricators,
with bigger Fabric migration projects we are facing more and more issues with limit of API calls to the Fabric API. As per my understanding, the number of API calls that can be sent to the API is limited per minute. While bigger capacities allow more API calls, we have experienced that the limits are being exceed across multiple client projects.
I wanted to ask if other users are experiencing the same and how you are dealing with it. We are trying to limit the API calls by moving them to the upper most job during scheduled runs, for instance making one API call to retrieve information in a notebook and passing this information to child NBs as parameter. Do you have additional tips on how to handle this?
Also is it known that the set limits are being lifted/changed?
Thank you for your input. 🙂
Hi ObungiNiels,
Thank you for the detailed and insightful response burakkaragoz, you've highlighted the key mitigation strategies very well. F SKU capacities do have more restrictive API call limits, which can be especially noticeable during largescale operations like Fabric migrations. Techniques like batching with retry logic, using multiple service principals, and scheduling tasks during off-peak hours are indeed best practices. It's great to see you're already optimizing API usage by consolidating calls at the parent notebook level. At this time, there hasn’t been a change in the documented API limits for F SKUs. For projects consistently hitting these limits, raising a support ticket or considering a temporary capacity upgrade is the recommended next step.
To raise a support ticket for Fabric and Power BI, kindly follow the steps outlined in the following guide:
How to create a Fabric and Power BI Support ticket - Power BI | Microsoft LearnIf this solution worked for you, kindly mark it as Accept as Solution and feel free to give a Kudos, it would be much appreciated!
Thank you.
2 Replies
Hi ObungiNiels ,
Yeah, you're absolutely right — F SKU capacities have pretty tight throttling on API calls, especially when you're hitting admin endpoints during large-scale migrations. We've seen similar issues when running parallel provisioning or bulk updates.
A few things that helped us:
- Queue and batch the calls using retry logic with exponential backoff. Even a small delay between batches can reduce the chance of hitting the per-minute cap.
- If you're using service principals, try spreading the load across multiple ones (with proper permissions) to distribute the call volume.
- Also, consider using the REST API during off-peak hours. Throttling tends to be less aggressive then.
As far as I know, Microsoft hasn’t officially lifted the limits for F SKUs. If you're consistently hitting the ceiling, might be worth escalating through a support ticket or considering a short-term capacity upgrade during the migration window.
If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.
Hi ObungiNiels,
Thank you for the detailed and insightful response burakkaragoz, you've highlighted the key mitigation strategies very well. F SKU capacities do have more restrictive API call limits, which can be especially noticeable during largescale operations like Fabric migrations. Techniques like batching with retry logic, using multiple service principals, and scheduling tasks during off-peak hours are indeed best practices. It's great to see you're already optimizing API usage by consolidating calls at the parent notebook level. At this time, there hasn’t been a change in the documented API limits for F SKUs. For projects consistently hitting these limits, raising a support ticket or considering a temporary capacity upgrade is the recommended next step.
To raise a support ticket for Fabric and Power BI, kindly follow the steps outlined in the following guide:
How to create a Fabric and Power BI Support ticket - Power BI | Microsoft LearnIf this solution worked for you, kindly mark it as Accept as Solution and feel free to give a Kudos, it would be much appreciated!
Thank you.
