We have desktop and mobile app (2 different client id) integrated with bim360 api. We have a problem with 429 error responses. Documentation: https://forge.autodesk.com/en/docs/data/v2/developers_guide/rate-limiting/ doesn't give us a lot of details.
How does it work? How can we avoid it?
What will happen if 1000 different users from apps with the same client_id at once try to get issues list? Will it be distinguish as Ddos? Are hubId, projectId, user account, ip address considered in rate-limiting algorithm?
As I know, each API has a well-configured rate-limit per minute per client id. After reaching the limit, you will see a retry-After parameter appears in the response header of each of your API call. It stands for the retry time when you can call the API again, and the unit of this value is in second. You can schedule a retry task along this retry time in your code.
Note. The value of the retry-After will reset if you make another call before reaching the Retry-After duration.
Hope it help, Cheers!
Related
We created a wallet pass and sent the wallet pass invitation email to end-users. However, there was an issue with the back-end APIs which prevented the Apple pass from automatically calling the device registration API.
The question I have is, do we need to re-inform all user to reinstall the Pass, or will the Pass automatically try re-registering by calling the device API.
Thank you.
The way you have worded your question possibly describes an impossible situation. A valid pass will always attempt to register. You state that your API was the issue, but an issue with a web service implementation would not prevent devices attempting to call it.
If the pass.json contains a valid https webServiceURL an authenticationToken, it will call the device registration endpoint after it has been added to the user's wallet. If the device does not get a 201 or 200 response, it will continue to retry, progressively backing off from every few seconds, to every few days for a period of around 2 weeks.
Therefore, if your pass.json contained the correct information; assuming that the issue was with your device registration endpoint and assuming that you picked up and addressed the issue quickly, then you should see device registrations coming in without having to do anything.
If it took longer than a couple of weeks or if you want to accelerate the process, you could ask your users to toggle the Automatic Notifications setting on the back of the pass. This will force the device to attempt a re-registration.
If however, the pass does not contain a webServiceURL, or if the webServiceURL was incorrect, then the device will not call back, or will call the incorrect endpoint. In this case, the only option is to have your users reinstall the pass. In this case, it is not your API that is causing the problem, but your passes.
I'm currently using the Google Places API to pull reviews onto a webpage. Everything is working fine except for the Photos of the people leaving reviews. When trying to get the photo of the reviewer, it's returning a 403 Forbidden on every other page load. It seems that there might be a rate limit perhaps?
The problem is I can't find any documentation about rate limits and how to get the picture to display without issue. Am I missing something in the docs?
My API call is this;
https://maps.googleapis.com/maps/api/place/details/json?placeid=PLACE_ID&key=API_KEY
That returns quite a long JSON array (I've cut it down). One of those fields is;
{
"result" : {
"reviews" : [
{
"profile_photo_url" : "//lh5.googleusercontent.com/url/photo.jpg"
}
}
}
}
Like I said, if I refresh a couple of times it'll cause a 403 error for the images get request. Anyway to cache or allow more requests?
I found out why this was happening. It's to do with rate limits on the photo media which is why it was giving a 403 error in the console. The developer docs outline the limits for the media requested.
An excerpt of the docs...
The Google Places API Web Service enforces a default limit of 1,000
free requests per 24 hour period, calculated as the sum of client-side
and server-side requests. If your app exceeds the initial limit, the
app will start failing. You can increase this limit free of charge, up
to 150,000 requests per 24 hour period, by enabling billing on the
Google API Console to verify your identity. A credit card is required
for verification. We ask for your credit card purely to validate your
identity. Your card will not be charged for use of the Google Places
API Web Service.
Best thing to do is to cache the media once it's requested to avoid going over the limit which is especially useful if you're reloading the page lots of times for testing local development changes.
I'm synchronizing Office 365 mail folders via the Office 365 REST API by doing a GET on me/MailFolders/{folder_id}/messages. For two different accounts, I've recently been getting 500 responses to these GETs with the error code ErrorMessagePerFolderCountReceiveQuotaExceeded and error message "The number of received messages has exeeded the quota for the folder." (Typo theirs, not mine.)
I can't find any documentation on this error. What does it mean? What should I do to fix this situation?
I couldn't seem to find any documentation for it either.
From the error message, it seems it might be related to the "Maximum number of messages per mailbox folder" limit on Exchange Online. Do you know if the folder contains 1M+ messages?
https://technet.microsoft.com/en-us/library/exchange-online-limits.aspx#MailboxFolderLimits
I guess my other idea would be that you're getting too many messages in too short of a time period. Suggestion would be to use the endpoint GET https://outlook.office365.com/api/v2.0/me/MailFolders('{folder_id}')/messages with $deltaToken and $skipToken to skip previously synced messages.
https://msdn.microsoft.com/en-us/office/office365/api/mail-rest-operations#synchronize-messages
When you do a sync to an Exchange folder via the Outlook REST API, you pass it a sync token. In response, the API returns a new sync token and a set of changes. And the client is expected to send the new token back with their next sync request.
With most systems that support sync, using a stale sync token (i.e. one that has been sent to the server once) in a subsequent request will generally just succeed with no problems. And Exchange appears to work like that... for the first 999,999 times you do it. On the 1,000,000th time (and each time thereafter), you get ErrorMessagePerFolderCountReceiveQuotaExceeded. This is (I think) because Exchange keeps track of each token that it's given out and updates the token in its store each time it's used for sync. If a client uses a stale token, Exchange views it as a new client and adds that stale token as a new entry in its list of active tokens. That active token list can have at most 1,000,000 entries. ErrorMessagePerFolderCountReceiveQuotaExceeded is the cryptic error indicating that Exchange's active token list has overflowed.
I use doPost() function callbacks a lot in my Google Apps Script projects.
Have rencently been looking for documentation regarding the max size to be admitted by GAS webapps expecting POST requests, to no avail. In the limits and quotas page, it mentions url fetch related data, which I presume refers to the URL fetch api calls, and not payloads of incoming POST request.
Anyone found info regarding this, has done tests, or can share any insight?
Thanks in advance.
After doing some tests, I uploaded data payloads using POST methods of up to 24MB without issues. Reached a "Max file size" limit with sizes beyond 24mb, but seems related to Drive rather than GAS.
I am using Google Maps service (Places, directions). After using for a while I am receiving response :
{ "error_message" : "You have exceeded your daily request quota for this API.", "predictions" : [], "status" : "OVER_QUERY_LIMIT"}.
I found this link Usage limits for services when used with Google Maps Javascript API v3. In this link it is mentioned that "Places API allows 1,000 or 100,000 (if you're verified) requests per 24 hours." But i have not requested it even for 200 times.
Is there some other reason for this response or is there any alternative to get rid of this problem. Thanks in advance.
Usage Limits for Google Maps API Web Services
Yes. There is another possible reason for getting the "Over query" message. And it's a common problem. If you make subsequent query requests too quickly, Google will respond with the over query limit message you posted.
From the Google API spec
Usage limits exceeded
If you exceed the usage limits you will get an OVER_QUERY_LIMIT status code as a response.
This means that the web service will stop providing normal responses and switch to returning only status code OVER_QUERY_LIMIT until more usage is allowed again.
This can happen:
Within a few seconds, if the error was received because your
application sent too many requests per second.
Some time in the next 24 hours, if the error was received because
your application sent too many requests per day. The time of day at
which the daily quota for a service is reset varies between customers
and for each API, and can change over time.
Add delay between requests to eliminate error
You need to insert a delay between requests to the Google Map API to get rid of the message and get the API to respond. How you implement a delay depends upon the platform you're using.