As stated in the documentaion user rate limit is flood protection. An application can only make X number of requests per second.
403: Rate Limit Exceeded The per-user limit from the Developer Console has been reached.
{
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "rateLimitExceeded",
"message": "Rate Limit Exceeded"
}
],
"code": 403,
"message": "Rate Limit Exceeded"
}
}
Suggested actions:
Use exponential backoff.
You can try adding quota user this helps sometimes.
quotaUser An arbitrary string that uniquely identifies a user.
Lets you enforce per-user quotas from a server-side application even in cases when the user's IP address is unknown. This can occur, for example, with applications that run cron jobs on App Engine on a user's behalf. You can choose any arbitrary string that uniquely identifies a user, but it is limited to 40 characters.
If you are getting a quota error then it has been exceeded even though you dont think it has. Application level quotas can not be increased. The only thing you can do is slow down.
Answer from Linda Lawton - DaImTo on Stack OverflowAs stated in the documentaion user rate limit is flood protection. An application can only make X number of requests per second.
403: Rate Limit Exceeded The per-user limit from the Developer Console has been reached.
{
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "rateLimitExceeded",
"message": "Rate Limit Exceeded"
}
],
"code": 403,
"message": "Rate Limit Exceeded"
}
}
Suggested actions:
Use exponential backoff.
You can try adding quota user this helps sometimes.
quotaUser An arbitrary string that uniquely identifies a user.
Lets you enforce per-user quotas from a server-side application even in cases when the user's IP address is unknown. This can occur, for example, with applications that run cron jobs on App Engine on a user's behalf. You can choose any arbitrary string that uniquely identifies a user, but it is limited to 40 characters.
If you are getting a quota error then it has been exceeded even though you dont think it has. Application level quotas can not be increased. The only thing you can do is slow down.
I could not find an answer to this question either. The default is 500 requests per 100 seconds, and even if I increased it, after some time, I can only make 5 requests/second which matches with a limit of 500.
That means the old default is always being used.
Calendar API, Rate Limiting, and Domain Wide Delegated Auth
Rate Limit Exceeded Issue with Google Calendar API Integration
Google Calendar "Calendar limits exceeded" error, but "Queries per minute" are way under the limit
Google Calendar "Calendar limits exceeded" error, but "Queries per minute" are way under the limit
Hey all, could use some help. I have two questions that are separate but may be related.
Building a SAAS app, in simple terms you can think of it as needing to create 100,000 Calendar Events in Google for multiple different Tenants, each of which have authorized the SAAS app to do this. This runs as a daily job.
Right now, the app uses an authorization code flow where an Admin in the tenant does an OAuth handshake which allows us access to the scopes we need to do the sync.
In order to create the events, we are using the batch API so we hit:
POST https://www.googleapis.com/batch/calendar/v3/
And then within that a bunch of:
POST /calendar/v3/calendars/{calendarId}/events
This allows up to 50 events per request.
GCP says you can also do up to 600 requests / minute (or 10 requests / second). And I saw that a single POST should count as 1 request, even to a batch endpoint.
The strange thing that’s happening is that I am getting rate limited even when calling Google way slower than 10 requests / second. Even stranger, if I use a batch size of 2 it seems to work fine, but if I use a batch size of 50 (at the same request rate) I get throttled. Even when slowing down my requests well below 10 / requests / second.
So my questions are:
Does it sound like I am doing something wrong here?
Should we be using domain wide delegated auth instead of auth code flow? I read somewhere this may impact rate limiting. The main hesitation here is that customer onboarding is more difficult using domain wide delegated auth than simple auth code flow.
Is there any relationship between batch sizes and throttling? I think my mental model is wrong for this works.
What am I not considering that may be causing me to get throttled?
Any help is greatly appreciated. Thanks!