Do we have any throttling\limits for request of access token for 1 Application in Azure Active Directory? I found unofficial limitations: 200 calls from 1 user for 30 seconds. This is true?
Shortly Yes you are right!
There is a concurrent API calling limits but what exactly the count it has not specified officially. If you refer this official docs you would know.
Its calls Throttling. When Throttling happens you would encounter 429 error code for that. You could check here See the screen shot below:
Best Practice:
Officially suggested following way to handle request limit:
Reduce the number of operations per request.
Reduce the frequency of calls.
Avoid immediate retries, because all requests accrue against your
usage limits
For more details you could check here.
Note: Calling limit also specifically doesn't specified on Azure AD service limits and restrictions
Related
Since requesting the Inventory from https://api.steampowered.com/IEconItems_730/GetPlayerItems/v1/ is permanently disabled I have to use https://steamcommunity.com/profiles/<steam_id>/inventory/json/2
Because of CORS I have to use my backend to provide the requested data. But when I do requests too often, my requests get rejected and my app cannot work on a large scale.
So the question should be simple: How can I avoid the rejection of my requests?
Any ideas and suggestions welcome.
Steam inventory endpoints are pretty heavily rate-limited, but there are a few different endpoints that you can use.
Trade offer endpoint
https://steamcommunity.com/tradeoffer/new/partnerinventory
This is the endpoint that's used when you open a trade offer with someone. It can be used to fetch both your own inventory as well as a trade partners. Required parameters are partner which is the user's Steam 64 Id, appid which is 730 in the case of CS:GO, and contextid which is 2 for most valve games. I don't know the exact limit, but I've been hitting this endpoint about once a second for a month with minimal 429 responses. To use this endpoint, you need to have a valid steam session and send the proper cookies along with the request. This will also only return tradable items.
Inventory endpoint #1
http://steamcommunity.com/inventory/STEAM64ID/APPID/CONTEXTID
Another inventory endpoint which has the same parameters but in the URL. I use this endpoint as a fallback to the first, but I've found that if the first endpoint is rate limited then this one will be too. That said, this one becomes limited much faster so it's best to use the first one instead.
Inventory endpoint #2
http://steamcommunity.com/profiles/STEAM64ID/inventory/json/APPID/CONTEXTID
The endpoint you're using. I don't use this one at all, but it could be worth knowing as another fallback.
Not all of them return the same data format, so be mindful. One inventory a second is a pretty solid rate for any decently sized site, especially if you limit user's ability to refresh inventories. If you need more though, you'll have to start looking into proxies.
My application accesses the directoryRoles resource via Microsoft Graph. This is done immediately after the Admin authorizes my client with the required scopes.
Usually, this flow works fine and calls to /directoryRoles returns a successful response. Intermittently, however, my application receives the following error:
{
'error': {
'innerError': {'date': '2020-02-18T20:06:49', 'request-id': <request_id>},
'message': 'Insufficient privileges to complete the operation.',
'code': u'Authorization_RequestDenied'
}
}
This happens even when the Admin has provided necessary authorization. I've also observed that in such cases, a retry after some time (say a min or two) returns success response.
Does this mean that it could take some random amount of time, spanning up to a minute or two, on the O365/Azure side to record the Admin's authorization for this resource?
Could there be some other explanation for such behavior?
Is retrying the API only solution in this case?
Would you have any other recommendations?
Appreciate any insight you could provide that would help me understand these intermittent errors.
Depending on the tenant's size and current load, it can sometimes take a moment or two for Azure AD to propagate consent for your application. This is normal and you should retry the request.
For the past few days i have been trying to access my discovery profile but it is showing -- 408 API request has timed out, I don't understand what it is i tried on different browsers and different systems.
A 408 HTTP response code is admittedly confusing in this case as 400-level errors typically indicate the client (browser) took too long to send the necessary information so the server timed out the connection when a preconfigured duration has been exceeded.
In this particular case, however, a 502 Gateway Timeout HTTP response would be more appropriate. There are multiple complex interactions happening with some of the pages in Watson Discovery Tooling and sometimes the service experiences slowness. In general, I would investigate the status page for the affected IBM Cloud services to determine whether or not there are any customer impacting events.
To check the status of Watson Discovery and any IBM provided service, I would check https://console.bluemix.net/status to see if any of the slowness or errors line up with your experiences.
Earlier today I noticed the following error in my logs:
503 Too many outstanding pull requests for subscription '<...>'.
Please reduce the number of simultaneous Pull() requests invoked for
this subscription. (POST https://pubsub.googleapis.com/v1/projects/<...>:pull)
I tried searching for the exact quantity of allowed simultaneous pull requests, but can't seem to find it anywhere. The only mention of this error I find is here in the docs, but again, no numbers are stated.
I have 40 processes pulling from the subscription.
This error happens when there is a transient overload on a specific instance of a Cloud Pub/Sub server to which some of your requests are being routed. The error message is admittedly poor and should not tell you to reduce your pull requests and I will remedy that.
I'm using stackoverflow in my meteor application,
I'm calling api directly from my code like below
HTTP.call("GET", urlString,{params:{site:"stackoverflow"}},function(error,result)
{
console.log(result.data);
});
I'm not using any oauth or client id secret id in my calls.
In the response, I'm getting a variable called quota. with maximum pings 300
Is that means I can only call the api for 300 times, I want more than that, I'm even ready to pay for it.
Is there a way to increase that number.
Thanks
You are throttled because you have not registered your application. If you register your application, you will receive a quota increase to 10,000 hits per day. You will want to read the authentication documentation on how to utilize the keys you receive from registering your application.