topic Re: REST API Activity Limitations in Developer

REST API Activity Limitations

Jefreaky — Thu, 21 Jan 2021 09:26:15 GMT

Hi all,

I am busy with a Power BI embedded implementation and we are running into issue with the service rejecting export actions due to too much activity

'{"error":{"code":"ActivityLimitReached","message":"You have too many pending requests to make another right now. Please wait."}}'

I have found information relating to the fact that there are API limits here, however I am unable to get any further info into these limitations and controls.

This makes is very difficult to do resource planning, is there any specific info around these limits.

I am specifically looking to answer the following questions

Do higher SKU's for PBI capacities provide more capacity for activity in the REST Service
What are the REST API activity limits for each SKU

Any Info here would be greatly appreciated

Re: REST API Activity Limitations

Anonymous — Mon, 25 Jan 2021 06:06:38 GMT

Hi @Jefreaky ,

Please review the content in the following links, hope they can help you.

Understanding the Power BI Capacity Based SKUs

Power BI REST API limitations

Rest API not allowing connections

Best Regards

Re: REST API Activity Limitations

Jefreaky — Wed, 27 Jan 2021 08:28:15 GMT

Thank you, I have managed to gather sufficient information relating to how this is behaving at the moment (Not all from the provided links however I will accept that answer, Thank you @Anonymous )

As a courtesy to the rest, please find some additional information I discovered through testing.

The limit of the Queue into which these requests go seems to not be limited by number of requests, but seemingly total size of all requests in the Q (I.e. the bigger the reports you send, the lower the number of individual requests that can go into the Q before your requests will starting being rejected)

There is info about reports requests over 250mb being entirely rejected all together (perhaps a correlation to the point above)

Exports can progress across reports simulataneously, rather than going one at a time from 0-100%, could potetially cause earlier requests to take longer than they should and cause user frustration, my preference is first in first out but regardless, your own Q as a middle man ensuring they are passed one by one requiring the previous requests completion before pushing the next is easily do able.

I am not certain about higher SKU's regarding Azure capacities but from embedded SKU A1 to SKU A2, the maximum size of the Q for these requests does not increase. (again I believe there is a correlation between that Queue size and the single report 250 mb size limit for requests.)

I hope people find this info useful.

Kind Regards,