Gmail Quota exceeded error / 429 response

Google Limits: GCP Project and Connected Account

There are two types of limits with Google: your GCP project and the connected account. All can be managed with exponential backoffs and by reducing the limit size and frequency of requests.

V3 Webhooks and Object Retrieval

In V3, webhooks contain rich payloads that can reduce the need for additional GET requests. However, you should still monitor your quota usage when retrieving objects, as V3 works within provider limits which are much lower than V2 Nylas limits.

Checking Google Console Project Limits

First, check your Google Console project if it is hitting any limits. The error message should correspond with the Metric.

Quota Limit Examples:

<HttpError 429 "Quota exceeded for quota metric 'Queries' and 
limit 'Queries per minute per user' of service 'gmail.googleapis.com' for consumer 
'project_number:XXXXXXXXXX'.">

OR

<HttpError 403 "Quota exceeded for quota metric 'Queries' and 
limit 'Queries per minute per user' of service 'gmail.googleapis.com' for consumer 
'project_number:XXXXXXXXXX'.">

Note: Google can return either 429 or 403 for quota errors.

Gmail Imposed Quota Limit

Every connected account has a Gmail-imposed 250 quota units per second limit. Different operations consume different amounts of quota:

Examples:

• Sending two emails per second = 200 quota units
• GET /messages?limit=50 = 250 quota units (50 messages × 5 units)
• GET /threads?limit=20 = 200 quota units (20 threads × 10 units)

This value is not definitive and fluctuates. Nylas recommends staying around 150 units per second to provide buffer and reduce 429 errors.

Why Queries via Nylas API Consume Quota

When making a query via Nylas API V3, each request may trigger multiple provider API calls. For example:

• Sending one email consumes approximately 100 units (one Gmail API send call)
• Listing threads is expensive because each thread may require fetching multiple messages

Prevention: Follow Nylas Recommended Limits

The following limits work well with most providers:

• POST /send: Once every 2 seconds (max)
• POST /send: Max 2,000 per day (Google's daily limit)
• GET /messages: Set limit parameter to 40 or less
• GET /threads: Set limit parameter to 20 or less (threads are expensive)

Resolution: Exponential Backoff

You should periodically retry a failed request over an increasing amount of time to handle errors related to rate limits. This method is called exponential backoff and is recommended by Google's documentation.

Exponential Backoff Example:

1. Initial request fails with 429
2. Wait 1 second, retry
3. If it fails again, wait 2 seconds, retry
4. If it fails again, wait 4 seconds, retry
5. If it fails again, wait 8 seconds, retry
6. Continue doubling up to a maximum wait time (e.g., 64 seconds)

Add jitter (randomization) to prevent thundering herd problems when multiple processes retry simultaneously.

Resolving Each Limit

Each limit can be resolved by:

1. Reducing the Limits on Queries

• Use query parameters to filter results (search_query_native, date ranges, etc.)
• Set lower limit values on list operations
• Evaluate whether you truly need to make each GET query

2. Reducing the Frequency of Queries

• Implement exponential backoff for retries
• Cache data locally where possible
• Use Nylas webhooks to stay updated instead of polling

3. Splitting Processing Across Multiple Accounts

• Distribute load across multiple Gmail accounts if your use case supports it

Note: Per-user limits cannot be increased by Google for any reason.

Resources

• Google Gmail API Usage Limits
• Google Gmail Sending Limits
• Google Workspace Quota Documentation
• Handling 429 Responses (Google)
• Nylas Rate Limits Documentation
• Nylas Error Handling Best Practices

Updated October 27, 2025 18:11