Understanding Email API Rate Limits and Throttling
Why email APIs have rate limits
Every email API provider enforces rate limits to protect their infrastructure, maintain sender reputation, and comply with ISP requirements. Sending too many emails too quickly from a new or low-volume domain triggers spam filters at ISPs like Gmail and Outlook. Rate limits ensure that email sending happens at a pace that maintains deliverability. AISend's rate limits are generous — the free tier supports 10 requests per second, and paid plans support up to 100 requests per second. Each request can include a single email, and the API returns a 429 status code with a Retry-After header when you hit the limit. Understanding and designing for rate limits is essential for any application that sends email at scale.
Designing for rate limits
Never send emails synchronously in a user-facing request handler. If a user action triggers an email (like a signup or purchase), add the email to a background job queue and return immediately. The job queue processes emails at a controlled rate that respects your API rate limits. This pattern also handles retries gracefully — if an API call fails due to rate limiting, the job is retried after the Retry-After delay. For batch operations like sending notifications to all users, use a rate-limited queue that processes emails at a steady pace rather than bursting. Tools like BullMQ (Node.js), Celery (Python), or Sidekiq (Ruby) all support rate-limited job processing.
Handling 429 responses
When you receive a 429 (Too Many Requests) response, check the Retry-After header for the number of seconds to wait before retrying. Implement exponential backoff as a fallback: wait 1 second after the first 429, 2 seconds after the second, 4 after the third, and so on, with a maximum delay of 60 seconds. Never retry immediately or in a tight loop — this will extend your rate limit and could result in your API key being temporarily suspended. AISend's SDKs handle rate limiting automatically with built-in retry logic and backoff, so if you're using the SDK, you get this behavior for free.
Warming up your sending volume
If you're switching to a new email API or adding a new sending domain, don't immediately send at your maximum rate. ISPs track sending patterns and flag sudden volume spikes as suspicious. Start with a small volume (100-500 emails per day) and gradually increase over 2-4 weeks. This process, called IP warming, builds your sender reputation with ISPs and ensures high deliverability from day one. AISend's AI handles warming automatically — when it detects a new sending domain, it gradually increases sending volume and distributes emails across providers to build reputation safely. You can monitor the warming progress in your dashboard.
Monitoring and alerting
Set up monitoring for your email sending pipeline. Track the number of emails sent per minute, the error rate (including 429s), the queue depth (how many emails are waiting to be sent), and the average time from queue to delivery. Alert on unusual patterns: a sudden spike in 429s might indicate a code bug sending duplicate emails, a growing queue depth might mean your sending rate is too low for your volume, and a high error rate might indicate a provider issue. AISend's dashboard provides real-time visibility into your sending metrics, but you should also monitor from your application side to catch issues in your queue and retry logic.
Ready to Send Smarter Emails?
1,000 emails/month free. No credit card required.