Definition
Email API rate limits define the maximum number of requests a client can make to an email service provider's API endpoints within a specified time window. Every major ESP implements rate limiting to protect their infrastructure from traffic spikes, prevent abusive usage patterns, and maintain consistent performance for all customers. Understanding and managing these limits is essential for building reliable email marketing integrations.
Rate limits differ by endpoint type and usage pattern. Sending endpoints typically have the strictest limits because they directly affect email throughput and server load. A typical sending API might allow 5,000 emails per hour per account, or 100 emails per API call with a maximum of 50 calls per minute. Management endpoints such as subscriber list updates, template modifications, and reporting queries usually have higher limits but may restrict concurrent requests. Webhook endpoints present a different challenge: instead of limiting outgoing requests, the ESP guarantees delivery through retry policies and expects the client to acknowledge receipt promptly.
Burst and sustained throughput limits represent two different constraints. Burst limits cap how many requests you can make in a very short period, such as 100 requests per second. Sustained limits cap average throughput over a longer window, such as 10,000 requests per hour. A well-designed integration stays within both limits by distributing requests evenly over time. Bulk operations should be batched into appropriately sized chunks, and retry logic must include exponential backoff to avoid creating retry storms that violate rate limits repeatedly.
Best Practices
- Read and map every rate limit before writing your first integration: Document the per-endpoint rate limits, burst limits, concurrent request limits, and daily caps for every API you plan to use. Store these limits in your integration configuration so you can programmatically respect them.
- Implement exponential backoff with jitter for all API retries: When you receive a 429 or 503 response, wait before retrying. Start with a 1-second delay and double it after each successive failure, adding random jitter to prevent thundering herd problems. Cap the maximum retry delay at 60 seconds and set a maximum retry count of 5 to avoid infinite loops.
- Batch bulk operations to minimise API calls: Instead of updating subscriber attributes one at a time, use batch endpoints that accept arrays of records. Typical batch sizes range from 100 to 1,000 records per call. Batching reduces API call volume by orders of magnitude and stays within rate limits more predictably.
- Monitor your rate limit utilisation in real time: Most ESPs include rate limit headers in API responses, showing your current usage and remaining capacity. Track these values and alert when utilisation exceeds 80% of the limit. Implement client-side throttling that queues requests when approaching limits rather than relying on server-side rejection.
- Negotiate higher limits during the contracting process: Rate limits are often negotiable during ESP procurement, especially for high-volume senders. Provide your projected peak-hour and peak-day volumes and request limits that include 2x headroom above your forecast. Document agreed limits in your contract with a process for requesting temporary increases.
Related Glossary Terms
Email Integration
The technical connections between email service platforms and external systems such as CRM, ecommerce, analytics, and customer data platforms for data synchronisation.
Email Rate Limit
Email sending rate limits per ISP vary significantly: Gmail ~100/second, Outlook ~30/second initially. Per-IP daily volume caps, detection, and self-regulation are essential for deliverability and sender reputation.
Frequently Asked Questions
The API returns a 429 Too Many Requests status code along with a `Retry-After` header indicating how long to wait before retrying. Repeatedly exceeding limits may trigger temporary or permanent IP blocking. Your integration must handle 429 responses gracefully by implementing the recommended retry delay and logging the incident for monitoring.
Burst limits control the maximum request rate over a very short window, typically 1 to 10 seconds, preventing sudden traffic spikes from overwhelming the server. Sustained limits control average throughput over a longer period such as an hour or a day. You must respect both types simultaneously: a burst of 200 requests per second might violate the burst limit even if your hourly average is well within the sustained limit.
Yes. Sending APIs typically have the most restrictive limits because each send consumes significant server resources. Management APIs for subscriber management and reporting usually have higher limits. Webhook delivery has its own constraints based on acknowledgement speed and failure rates. Always check per-endpoint documentation rather than assuming uniform limits across all API operations.
Data migrations require careful rate limit management because they involve high-volume operations that can easily exceed limits. Break the migration into batches sized according to the API's limits, insert delays between batches, and prioritise critical data over supplementary fields. Consider requesting a temporary rate limit increase from your ESP for the migration period.
Using multiple API keys to circumvent rate limits violates the terms of service of every major ESP and can result in account suspension. Rate limits are enforced at the account level, not the API key level. Instead of trying to bypass limits, work with your ESP to negotiate appropriate limits for your sending volume and integration needs.