My PAID App Engine is restricting me to sending only 100 mails. I could not find any documentation to increase that limit.
Additionally it says there is 0.00/100 $ charge for mails exceeding 100 mails. I could not find any information on the billing documentation either - in terms of how to send mails beyond 100 and get charged for it/etc..
Any help is welcomed..
Google doesn't appear to be interested in directly offering the email sending service, so the quota is really small nowadays. Instead they have partners for this service, which you'd have to use if you need to exceed the quotas.
From Quotas and limits:
The quota is reset daily. If you exceed the daily quota, you will get
an over quota exception. If you need to send more mail then the
quota allows, you can use a third-party mail provider, such as
SendGrid or Mailgun.
In addition to Mailgun and SendGrid, Mailjet is also a mail sending partner.
Related
Our application makes use of a service account that has been authorized for the entire domain by the admin. With this service account our application accesses the domain user's emails with Gmail APIs like GetMessage.
All of a sudden, starting this week, we have started receiving the errors intermittently
Quota exceeded for quota metric 'Queries' and limit 'Queries per minute per user' of service 'gmail.googleapis.com' for consumer 'project_number:XYZ
There is no change in our application or frequency at which we access emails. We are using batch size of 10 while using the API.
The 'Quota exceeded errors count (10 sec) - Queries per minute' graph in the GCP dashboard is empty. So we are really not sure what is going on and why we are suddenly hitting the quota limits.
Also, I am not sure how the 'per-user' limit is applied when my app accesses the user mailboxes with the service account. The documentation around this is vague, at least to me.
These errors are really impacting our ability to serve our customers. Moreover not knowing why we are getting these errors is shaking our confidence in the Gmail APIs.
Any help in this regard is highly appreciated.
Thanks
UPDATE:
Today we are seeing lots of
"User-rate limit exceeded. Retry after <timestamp>"
errors. Seems like this time around we are hitting some quota limit other than 'queries per minute'. While I look in my client implementation and figure out why this is happening, feel free to share any recommendations you may have.
Thanks.
Google analytics has limits and quotas on API requests. You can increase it. If you don't want to do it, daily quotas are refreshed at midnight Pacific Standard Time.
Can someone tell me if the tokens from Gmail are limited for applications or for users ?
For example I will create a SAAS where users will be able to log in with their Gmail account.
The tokens are limited for the website owner or for website users ?
Thanks
Gmail's usage limits are applied to all requests made from your application, as well as per-user rate limits:
Daily Usage: 1,000,000,000 quota units per day
Per User Rate Limit: 250 quota units per user per second, moving average (allows short bursts)
For more information, see the docs: https://developers.google.com/gmail/api/v1/reference/quota
I sometimes get the following error when creating a subscription:
Insufficient tokens for quota 'administrator' and limit 'CLIENT_PROJECT-100s' of service 'pubsub.googleapis.com' for consumer 'project_number:'
Waiting it out does the trick, but I'd like to increase the quota. In the IAM & Admin section of the Google Cloud Console, I can filter on the Pub/Sub API, but can't find the limit...
You are running up against the quota for administrative operations. In the Quotas page, under "Quota type," select "All quotas," then under "Service" select "Google Cloud Pub/Sub API." The quota you want to increase is "Administrator operations per 100 seconds," which you can update up to the maximum allowed limit of 10,000 per 100 seconds, as detailed on the Pub/Sub quota page. Here is a screenshot of the entity you need to update:
I was hitting a similar error.
I checked the quota section — as per Kamal Aboul-Hosn's suggestion — however it was already maxed out.
A work around was to put a sleep function in the code so the API wouldn't get hammered over a hundred second period. I hope that helps.
According to AboulHosen on the GCP Slack:
"It does look like quota is pooled across users of the default application credentials and that the quota is significantly lower for users authenticated in this way. I believe when going to app engine, a service account is created (https://cloud.google.com/appengine/docs/flexible/python/access-control#using_service_accounts), so I would not anticipate this error happening when running on app engine."
So the reason this is happening is because the quota for your admin credentials is being consumed elsewhere, and as far as I know, there is no way to increase this!
According to the docs: https://developers.google.com/appengine/docs/quotas#Channel
The daily quota for billing enabled apps for sending data through the Channel API is capped at 2GB. Is this correct?
I think it's too small. If I had an app that sent data every 5 seconds (at 32KB per message) for an hour, I'd be over the quota in an hour with only 90 users. This 2GB volume cap for a cloud solution seems a bit too small.
Am I missing something?
I don't think it is correct. My billing enabled app shows this in the Quota Details:
Channel Data Sent 0% 0% 0.00 of 2,088.13 GBytes
You need to become a Premier customer by joining Silver, Gold, or Platinum support in order to ask for anything beyond the documented limits.
The quotas page says this:
Is your app exceeding the default limits? If you are a Premier customer, you can request additional quota bycontacting support.If you are not a Premier customer, you can apply for more Mail API quota orfile a feature requestfor any other quota increase.
My mail is regarding the option for receiving email to any address which looks like - xxx#appid.appspotmail.com documented here: http://code.google.com/appengine/docs/python/mail/receivingmail.html
My questions are:
Is there any restriction on the number of email addresses which can be created using the above format and used inside the application?
As an example I may have a million users and could have some sort of a "in-mail" facility where each user is assigned a unique "xxx" id.
Is there any limit on the number of emails which can be received by an address of the above format? I don't see any quota restrictions specified anywhere?
There's no limit to the number of email addresses you can send or receive email on. Incoming email is simply sent to your handler with the address preserved; no accounts get created, so there's no reason to limit the number of unique addresses. The system-wide quota limits on incoming mail, total requests, and calls to the mail API are the only ones that apply here.
There is no limit on the number of addresses where your app can receive mail, or the number of emails it can receive.
App Engine does not persist the addresses you've used to receive mail; each inbound message is handled like an HTTP POST and then discarded. Sending a million emails to one address or a to million addresses will use the same resources.
The mail-related quotas apply to sent mail only. For CPU, bandwidth, etc., inbound mail draws from the same resource pool as your HTTP requests. There's no indication in the docs of any quota specific to inbound mail.
I can't see any mention of a maximum of email addresses you can have in the format
string# appid.appspotmail.com. But surely there must be some internal limit specified. I guess the appspotmail option is not meant to be used to create unique emails for each of your app's users (especially if you have a large number of users).
There are limits specified in the quotas, for example you can send mails to a maximum of 7,400,000 recipients a day, and you can make a maximum of 1,700,000 calls a day to the GAE Mail API (both limits apply only when billing is enabled). So if you had a million users, you probably would reach the API limit pretty soon when most of them would receive one or multiple emails.