What are ESP API rate limits?

You're building an integration with your ESP, you hit send, and suddenly you're getting back a 429 Too Many Requests error. That's a rate limit. And if you haven't planned for it, it can stall your whole pipeline.

API rate limits are caps that ESPs put on how many requests you can make to their systems in a given window. Every major ESP has them. Twilio SendGrid, Mailgun, Postmark, Amazon SES, Mailchimp. They all do it, though the numbers look different depending on what you're doing and what plan you're on.

The limits usually come in a few flavors. Requests per second is the tightest. Requests per minute or hour is more forgiving. Then there are daily sending caps, which hit senders on starter plans more often than developers expect. Some ESPs also have burst allowances: short-term headroom above your normal rate for spikes, as long as you don't sustain that pace.

Transactional APIs (like Postmark or Mailgun) tend to allow higher rates than marketing campaign APIs (like Mailchimp's list management endpoints). That makes sense. A triggered email after a user action needs to go out fast. A bulk list import doesn't. Enterprise tiers typically get higher limits, but the structure is the same.

Here's what to actually do when you're designing around these limits.

Build retry logic with exponential backoff. When you get a 429, don't immediately retry. Wait, then retry. Then wait longer if you get another 429. A simple version looks something like this:

wait = base_delay * (2 ** attempt_number)
sleep(wait + small_random_jitter)

So the jitter matters. If multiple processes all retry at the same time, they'll all hit the wall together again.

Batch where you can. Most ESPs let you send to multiple recipients in one API call, or import contacts in bulk rather than one at a time. One call for 1,000 records beats 1,000 calls for one record each, every time.

Spread your requests over time. If you're doing a large list sync or a big send job, don't fire everything at once. Queue your requests and pace them below the limit. A job that takes 10 minutes instead of 30 seconds is fine if the alternative is getting throttled and starting over.

Read the response headers. Most ESPs return rate limit headers in every API response. Headers like X-RateLimit-Remaining and X-RateLimit-Reset tell you how much headroom you have and when the window resets. Use them. Don't guess.

Know your plan's actual limits before you build. Not after you hit a wall in production. Check your ESP's API documentation for the specific endpoints you're using, because limits often vary by endpoint (sending vs. analytics vs. list management).

Now if you're consistently hitting your ceiling even with all of this in place, that's usually a sign you've outgrown your current plan tier, or you need to look at whether your integration is making more calls than it actually needs to. Sometimes a simple caching layer on analytics queries cuts your API usage in half without any other changes.

If you're integrating your ESP with a validation or hygiene tool, the same rate limit logic applies to those API calls too. Something worth keeping in mind when you're architecting the whole flow.