Looking for feedback: Fabric Job Public API throttling – what are your real scenarios?

[zhaya]

Hi everyone
I’m part of the Microsoft Fabric team, working on the Fabric Job Public APIs.

We’ve heard feedback from several customers (FabCon, interviews, direct conversations) that the current throttle limit — 100 requests per minute per user — is not sufficient for some real‑world scenarios.

Before simply increasing this number, we want to better understand the actual pain points and usage patterns, so we can design a solution that scales safely and avoids unintended abuse or platform impact.

I’d really appreciate your help by sharing:

• What job API calls are you hitting most frequently? (e.g. submit job, get job status, list jobs, cancel jobs, etc.)

• Is the pressure coming from automation, event‑driven workflows, fan‑out polling, or something else?

• Are you managing many jobs in parallel, or many pipelines/workspaces/capacities?

• Is this mainly a burst problem, or sustained traffic over time?

• What would an “ideal” solution look like for you? (Higher limits? Per‑workspace or per‑capacity limits over per user limits? Batch APIs? Webhooks/events instead of polling? Something else?)

To be clear:
We are not ruling out increasing the limit, but we want to avoid a one‑size‑fits‑all change that could create reliability or fairness issues for everyone.

If you’ve run into throttling and can share concrete scenarios (even anonymized), that would be extremely valuable and will directly influence the design.

Thanks in advance — really looking forward to learning from your experiences.

[v-nmadadi-msft]

Hi @zhaya 

May I check if this issue has been resolved? If not, Please feel free to contact us if you have any further questions.

Thank you

[v-nmadadi-msft]

Hi @zhaya 

I wanted to check if you had the opportunity to review the information provided. Please feel free to contact us if you have any further questions.

Thank you.

[zhaya]

Thanks for you feedback @tayloramy ! 

The API limit is applied at the per-item level. Therefore, if you need to orchestrate multiple items, the effective number of requests becomes 100 × n. If this limit is insufficient, what scale of limit do you think would be adequate for your scenario? Additionally, how frequently would you need to poll status updates to satisfy your “real-time” requirements? every min, few sec?

[tayloramy · Accepted solution]

Hi @zhaya, 

The perfectionist in me wants to poll the API every few seconds so there is the least delay possible in detecting that one job finished successfully and kicking off the next job, though that might not be realistic unless there was a websocket api available. 

I switched my stuff over to poll every 5 minutes I think and that resolved the API errors, though waiting 5 minutes between jobs can add up in very large enviornments. 

You said that the current limit is applied at the item level? Has that always been the case? 
If that is true, then I should be able to poll every running job every second without hitting limits, as that would only be 60 requests a minute. That is not what I experienced. 

Some background for what I was doing: 
I was working in a rather large environment, we had 3 F64 and 2 F128 capacities. 
I was trying to build a system to robustly orchestrate jobs with complex dependency chains (so using a Pipeline to orchestrate wasn't enough) 

I'm no longer at the company I was at when I was doing this, so I don't have any of the code anymore. 

[tayloramy]

Hi @zhaya, 

From my perspective the 100 requests per minute for starting jobs is more than enough, however the 100 requests per minute for getting job statuses has been a bottleneck for me. 

I was using these APIs to build my own orchestration system that can handle more complex rules than pipelines can handle, and when polling the status of jobs to determine what to run next, I frequently ran into throttling on the API. 

I attempted to get around this by using Activator to watch for job events, and while that worked, it took about 10 minutes after a job started, finished, or failed for the event to appear in activator, which was too much of a delay. 

For my use case, if there was a wehbook that I could use to get events instead of polling the API, that would be amazing, provided that the webhook is faster than events flowing into Activator are.