We are working with Google's Admin SDK API. We get a lot of 403 (Rate limit exceeded) errors when we execute more than 2 threads making batch requests to Google's servers.
We have changed the Rate Limit of Requests per second in the project admin panel but it seems to have no effect. As google recommends in https://developers.google.com/admin-sdk/directory/v1/limits we have tried with one user's credential per thread.
How many requests per second can we actually send?
Is there any way apart from contacting Google to increase that Rate limit?
Thanks in advance.
You can submit quota request to increase you query limit by going to API console (https://code.google.com/apis/console/
). Go to the quota pane and click "Request more" next to Admin SDK. A form should show up, and you can submit your request. Make sure you include your calculation and justification.
You're probably requesting new access tokens for every request. See my answer at https://stackoverflow.com/a/24211132/1135732
Related
I have created an app in Django. Using Twilio Verify API (free trial) for OTP.
Problem:-
It's working fine but when a user try to get the OTP multiple times, Twilio creates an exception "HTTP 429 error: Unable to create record: Too many requests". After this I was not able to use this for the whole day even for different mobile number or device.
How to bypass this issue and precisely what is the reason behind this issue?
Twilio Developer Evangelist here. The Verify API has rate limits for sending SMS codes to the same phone number, ~5 requests within 10 minutes. I'm not sure why it wasn't working with a different phone number, though - let me know if you're still having issues after you try the below.
You're definitely not the first person to run into this issue, so I have a blog post that should answer the question: How to test Twilio Verify without getting rate limited
tl;dr your options include -
Complete a verification lifecycle by calling the Verification Check endpoint
Wait for the verification to expire (in 10 minutes)
I also recommend spinning up a Verification Testing Dashboard that will help you check/cancel a verification during development.
Here's another blog post about managing retry logic that's also designed to prevent hitting API rate limits: https://www.twilio.com/blog/best-practices-retry-logic-sms-2fa
This may have been solved by now but for anyone else it's possible that the free Twilio trial account has expired or used up it's allocated requests. This happened me as I had forgotten I was using a trial account in a test environment, and when tests started to fail this was the issue.
I encountered the same problem with email channel when a user tries to send verify api multiple times and gets this error. All other emails would get the same error, and nobody can get verified. This looks to me that one user gets rate limited and it could affect all other users.
Last year I was building an application to create my own YT dashboard.
It was based only the code of a tutorial
They basically authenticate a user via OAuth and send requests to get channel data or playlists of the authenticated user.
I was trying out both the original tutorial app and my own (after a few dormant months) and they suddenly don't work anymore.
Meaning: I can authenticate on both, but on the original version I get a 403 error telling me: "The request is missing a valid API key." (on requesting channel data)
This is confusing because the API key is never used because only the OAuth client id was necessary.
And on my own fancy version, I get a 403 error telling me that I've exceeded my getting started quota. (on requesting the users playlists)
Looking at my quota page:
I can see, that queries per day (why is it there twice?) is somehow set to 0.
Perhaps creating a new OAuth 2.0 Client ID or a new API key would solve these errors, as was suggested in another post.
But since I'm planning to use the YT Data API in a real project soon and want to prevent this from ever happening I would like to understand what was going on. Why the daily quota limit is suddenly turned to 0 and how to go about it when that happens.
Or at least how to contact google about it.
Perhaps some of you have some insights.
UPDATE:
I've just found this post reporting, that after 90 inactive days, the quota is automatically set to 0.
Now I created a new OAuth Client Id and replaced the constant in my code. Nothing changed so far. Perhaps I have to wait 24h. Or perhaps I have to fill out this form which apparently can lead to months of back and forth email nonsense. I sure hope not.
It seemed the only viable option was to create a new project with new credentials.
(And one should not forget that the YT Data API has to be enabled again for the new project.)
Does anyone know why my app would have a 100 user cap, even though the Verification Status is "Published"? It says "the user cap will be in place until the app is verified by Google", but this is already the case. I would appreciate any insight.
The 100 users cap is a quota limit for unverified scope requests, it is applied when the application tries to obtain access to scopes that have not been approved for the project during the app verification process, see this. Since you're seeing this quota being actively used you should check whether the scopes requested by your application match the ones you submitted in the app verification status. In case there is a mismatch you would need to update the requested scopes and go through the verification process once again. Optionally you might also request a OAuth quota increase with this support form, but bear in mind there's no approval guarantee.
Finally, as Pievis pointed out this kind of inquiries would be better handled by Google Cloud Support team as they have the necessary information about your project to address your questions from end to end.
We're looking to replace an existing API manager with wso2 and one of the features of the other platform is that we can identify a 'user' of the API at run time and have the throttling work.
The 'user' is not OAuth identified, rather they authenticate via the API and a session id is returned (so they've never registered at a 'store'). This session id is then used to setup the throttling at the API Manager. Additionally the other tool has code to look for the user logging in and using that id in the throttling. so if a user tries to login too many times per hour the API manager blocks the request in addition to too many requests for a logged in user per hour. The combinations of login attempts, API calls etc. are summed into the throttle. (All this was implemented by their services team years ago)
The main reason we need this is we don't want to force our old clients to go to OAuth immediately but want much more visibility, reporting and throttling.
Thoughts on how to do this with wso2? I see where we can add our own Handlers to the API to figure out session ids, login ids etc. but I don't see where to create the logic to do the throttling.
Thanks,
Chris
Login to Carbon and edit the tiers.xml (/_system/governance/apimgt/applicationdata/tiers.xml)。You can found the section <throttle:ID throttle:type="ROLE">Unauthenticated</throttle:ID>
I'm working on kind of CRM project that has 3 main processes
Send messages to our custommers
I've read that facebook currently prohibit sending messages through API for spamming reason. Any alternative? Maybe use dialogues API? Using Dialogues API still could be spamming? That's not spam though. We have careful inner processes.
Posting on wall(me/friends) for many authenticating accounts on a server.
Other post ( Publish limit on Facebook's Graph API ) said that there is a publishing limit (bucket allocation for each token/profile. 20-24 per day at that time). Is that still working policy? Does that include posting both on my wall and friends? or only friends? me?
Get responses from our customers for many authenticating accounts on a server.
Also concerning there could be some limits.
I've read that there is a 600/600sec API limit. Is that per access token? or per IP? per application? Is that for GET request? for POST or both?
thanks