There is 429 error when request to Google People API - google-people-api

I'm having error with 429 code when I request to Google People API. Message: "Resource has been exhausted (e.g. check quota)" But quota wasn't exceeded, there was 5-10 requests per day at all during last 6 months.
After 30th of March all my requests returned with error 429.
Does anybody met this problem?

Related

Google People API people.connections.list has an additional quota

Google's docs for people.connections.list say the following:
The first page of a full sync request has an additional quota. If the quota is exceeded, a 429 error will be returned. This quota is fixed and can not be increased.
Does this mean that after you do the first sync, you're not supposed to trigger the full sync again for a while or you may get blocked by google with status 429, or does this mean something else?

Amazon AWS SES Error - Throttling failure: Maximum SigV2 SMTP sending rate exceeded

The error Throttling failure: Maximum SigV2 SMTP sending rate exceeded. suddenly started to appear in our .NET application though there were no exceeding any quota (14 mails per second or 50000 per day) in our AWS Sending Statistics.
I can see many similar issues about Throttling – Maximum sending rate exceeded on StackOverflow but I'm confused about SigV2 in my error message.
Searching in other resources like this one gave me the idea that this issue started to happen recently from about October 20, 2020, and there is no exact answer to why this happened. The only solution I can see is to migrate from using SigV2 signing process to the new method.
The question is: Why this happened and can this issue be solved without changes in the application code?
This is not a service quota issue. The issue you are facing is due to excessive authentication requests from your side. This issue will not occur if you renew your SMTP credentials in the SES console to use Sigv4 credentials.
https://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-credentials.html
As you can see your daily rate exceeded
But you can open a case and increase your maximum rate

paymentState does not change from Trial period

I am implementing in-app subscriptions with Google Play and synchronize the status of those through polling to Google Play API. The subscriptions have a trial period of 3 days and I expect Google API to return paymentState=0(Pending) or 1(Received) after the trial period has expired. This does not always happen for customers that have a payment failure, as Google keeps returning paymentState=0(Free trial).
It seems Google is giving a grace period, although I don't have any grace period configured for this subscription type.
Do you know why this happens and how should I update the trial period status when the 3 days of trial have expired?
Thanks
Reported this several times to google, the issue is still present, from my experience for some orders the SUBSCRIPTION_GRACE is sent >20 hours after the current cycle ends, and if you send validation request before this notification paymentState will still have value 1 or 2 instead of 0.

How do Facebook graph errors get counted for within the total api errors?

Ever since we started batching our requests our total requests in the App Dashboard API stats went down 50% a day, and our error rate grew by 200% a day.
If you get throttled doing batch requests... n number of requests will return an error. For example:
I make 50 requests in a batch and the first 20 requests are good. At request 21 our account gets throttled, so requests 21-50 all receive a throttling error.
Does this count as 30 errors or 1 error in the API stats?

When using the Admin SDK directory API to insert Org Units a dailyLimitExceeded error is returned even though that quota has not been reached

I work for an Student Information System and we're using the Admin SDK directory API to create school districts Google Org Unit structures from within our software.
POST https://www.googleapis.com/admin/directory/v1/customer/customerId/orgunits
When generating these API requests we're consistently receiving dailyLimitExceeded errors even when the district's quota has not been reached.
This error can be bypassed by ignoring the error, and implementing an exponential back-off routine, but I believe this to be acting much more like the quotaExceeded error is intended to act rather than dailyLimitExceeded, in that the request succeeds afterward on the first retry of this request.
In detail, the test I just ran successfully completed 9 of these API calls and then I received this response on the 10th:
Google.Apis.Requests.RequestError
Quota limit exceeded for the day. [403]
Errors [Message[Quota limit exceeded for the day.] Location[ - ] Reason[dailyLimitExceeded] Domain[usageLimits]
From the start of the batch of API calls it took about 10 seconds to get to the point where the error occurred.
Thanks for your help!
What I would suggest is to slow down your API requests. Don't make like 10 requests in 1 second. Give it a space in between requests. You are correct to implement exponential backoff. Also, if you can, use other accounts as well to make requests.