Nylas API and provider rate limits

Rate limits apply when you make requests to the Nylas APIs and add account information in the Nylas Dashboard. For best practices to mitigate rate limits, see Avoiding rate limits in Nylas.

Nylas rate limits

The table below describes API rate limits for Nylas. These apply to all endpoints.

API	Type	Rate limit	Expiration
Applications	General	Up to 50 requests per application.	1 second
Authentication	General	Up to 50 requests per application.	1 second
Calendar	General	Up to 200 requests per grant.	1 second
Connectors	General	Up to 50 requests per application.	1 second
Contacts	General	Up to 200 requests per grant.	1 second
Grants	General	Up to 50 requests per application.	1 second
Messages	General	Up to 200 requests per grant.	1 second
Send	application/json	Up to 200 requests per grant.	1 second
Send	multipart/form-data	Up to 10 requests per grant.	1 second
Webhooks	General	Up to 50 requests per application.	1 second

Threads rate limits

The Get all Threads endpoint makes a significant number of calls to the provider for each request you make. We strongly recommend using query parameters to limit the threads data you receive.

Because of the number of calls Nylas makes to the provider for each Get all Threads request, you might encounter rate limits when working with large threads of messages. You can take the following steps to avoid rate limits:

• Specify a lower limit to reduce the number of results Nylas returns.
• Add query parameters to your request to filter for specific information.

Provider rate limits

Not all IMAP providers publish information about their rate limits. If you have questions, contact your provider’s customer support team.

Nylas’ API requests are also subject to rate limits for the underlying providers. Keep these in mind as you build your project.

When a provider throttles a request, the API returns a 429 right away. Nylas doesn’t retry a throttled read or send request for you. If the provider says how long to wait, the response includes a Retry-After header with that number of seconds, rounded up. This covers every Email, Calendar, and Contacts endpoint, including send, for Google, Microsoft, EWS, iCloud, and Zoom grants. On reads, error.type is rate_limit_error and the provider’s own error is in provider_error. IMAP rate limits never include Retry-After, and neither do sends from Yahoo, iCloud, and other IMAP accounts, which go out over SMTP. Whenever a 429 arrives without the header, use your own backoff schedule. The provider 429 table lists the message and Retry-After behavior for each provider, and How to handle rate limit errors has retry examples.

Google rate limits

As of February 2024, Gmail has new requirements for accounts that send more than 5,000 messages per day. For more information, see Google’s official documentation.

Google has several sets of rate limits to keep in mind:

• Overall usage limits: 10,000 requests per minute, per application and 600 requests per minute, per user. Google calculates these limits within a one-minute sliding window.
• Message sending limits: 2,000 messages per day. See Google’s Gmail sending limits in Google Workspace documentation.
• Gmail API limits: For Cloud projects created on or after May 1, 2026, a per-project limit of 1,200,000 quota units per minute and a per-user limit of 6,000 quota units per minute. Projects that used the Gmail API between November 2025 and April 2026 keep their previously set quotas. See Google’s Gmail usage limits documentation.
• Google Calendar API limits: API usage quotas, general usage limits, and operational limits. See Google’s Calendar quotas documentation.

A single Nylas request might make multiple calls to Google’s APIs. Nylas returns a Nylas-Provider-Request-Count header that shows the number of calls it’s made to the Google APIs, and a Nylas-Gmail-Quota-Usage header for requests to Nylas’ Drafts, Messages, Threads, Folders, and Attachments endpoints that shows how much of your Google API quota Nylas used for your request. We recommend monitoring these headers and spacing out your requests to avoid being rate-limited.

Microsoft rate limits

Microsoft Graph applies its limits to each app ID and mailbox combination. The app ID is the Azure application your grants authenticate through, so the user’s own Outlook clients don’t count against your budget. One throttled mailbox doesn’t affect any other mailbox. Keep these limits in mind:

• Overall usage limits: 10,000 requests per 10-minute period, a maximum of 4 concurrent requests, and a maximum of 150 MB uploaded per 5-minute period, each per app ID and mailbox. See Microsoft’s Outlook service limits documentation.
• Message sending limits: 30 messages per minute and 10,000 recipients per 24 hours, per mailbox. See Microsoft’s Exchange Online limits documentation.

The concurrency limit is the one most integrations hit. A 429 with the message Application is over its MailboxConcurrency limit means 4 Graph requests were already in flight against that mailbox when another arrived. Because a Send Message request makes several Graph calls and shares the slots with other traffic under the same app ID, 2 or 3 parallel sends to the same grant can fill all 4. Send to each grant one request at a time. For the full explanation and per-grant queue examples, see Microsoft Graph rate limits for Outlook mail.

A single Nylas request might make multiple calls to the Microsoft Graph APIs. Nylas returns a Nylas-Provider-Request-Count header that shows the number of calls it’s made to the Graph APIs for your request. We recommend monitoring this header and spacing out your requests to avoid being rate-limited.

If Microsoft says how long to wait, the response includes a Retry-After header with that number of seconds, on reads and sends. On reads, a MailboxConcurrency rejection returns the message Microsoft rate-limited on application level, with Microsoft’s own text in provider_error.

EWS rate limits

Your EWS administrator configures the rate limit for your on-premises Exchange server, so Nylas cannot know the server’s actual rate limits. If your Exchange server rate-limits a request, the response includes the server’s Retry-After value, which shows the number of seconds you have to wait before the server will accept another request.

iCloud rate limits

Apple limits the number of messages you can send to 1,000 per day. For more information, see Apple’s Mailbox size and message sending limits documentation.