Why limits matter for bulk updates
A routine automation that adds one subscriber at a time never notices an API rate limit. A one-off job that touches your whole list does: backfilling a custom field, retagging after a migration, or syncing a CRM status to 20,000 contacts. Push faster than the platform allows and requests start failing with HTTP 429 errors.
The limits below come from each vendor's developer documentation. Moosend is not covered here; check its own API documentation for limits before a bulk Moosend run.
Documented limits and 429 behavior
Two details are easy to miss. beehiiv gives each API key and each OAuth token its own allowance, and enforces the first request from an idle credential at the default 180 per minute, so do not size a Free-plan script from that first response: after it, the 30-a-minute Free limit applies. [6] MailerLite's batch documentation says webhooks are not supported inside batch requests and that the global rate limit still applies alongside the import limit. [2]
| Platform | Request limit | What happens above it | Bulk or batch option |
|---|---|---|---|
| MailerLite | 120 requests per minute, global; import creation 5 per minute [1] | 429 with X-RateLimit-Remaining and Retry-After headers [1] | Batch endpoint: up to 50 requests per call; all-upsert batches count as imports at 5 per minute [2] |
| Kit (V4) | 120 requests per rolling 60 seconds per API key; 600 with OAuth, window not stated on the page [3] | Not described on the authentication page [3] | Bulk endpoints need OAuth; over 100 subscribers runs async with a callback URL [4][5] |
| beehiiv | Per minute by plan: Free 30, Lite 180, Pro 500, Enterprise 800, in fixed 60-second windows [6] | 429 Too Many Requests; RateLimit-Remaining and RateLimit-Reset headers on every response [6] | Bulk subscription update: up to 1,000 subscriptions per request, including custom fields [7] |
Worked example: updating one field on 20,000 contacts
Assume you need to set a custom field, say "plan" or "region", on 20,000 existing subscribers, with the subscriber IDs already in hand so each update is one request. The minimum times below are the request count divided by the documented limit; real runs are slower because of network time and any lookups.
On MailerLite, 20,000 single updates at 120 a minute take about 2 hours 47 minutes. [1] Using the batch endpoint with 50 upserts per call cuts it to 400 calls, but an all-upsert batch is processed as an import at 5 a minute, so plan on 80 minutes. [2] MailerLite's docs do not say how a mixed batch counts against the 120-per-minute limit, so budget for the import pace.
On Kit with an API key, 20,000 updates at 120 per rolling minute also take about 2 hours 47 minutes. [3] Kit's bulk endpoints are faster but require OAuth [3][4], and Make's Kit app connects with an API Secret [8], so a Make scenario will normally go one subscriber at a time.
On beehiiv, the plan sets the pace for single updates: about 11 hours 7 minutes on Free, 1 hour 51 minutes on Lite, 40 minutes on Pro and 25 minutes on Enterprise. [6] The bulk update endpoint takes up to 1,000 subscriptions per request, so the whole job is 20 requests [7], and Make's beehiiv app includes a batch update action for subscribers. [9]
| Method | Requests needed | Documented limit | Minimum time |
|---|---|---|---|
| MailerLite, one update per contact | 20,000 | 120 per minute [1] | About 2 h 47 min |
| MailerLite, batches of 50 upserts | 400 | 5 per minute import limit [2] | 80 min |
| Kit, API key, one per contact | 20,000 | 120 per rolling 60 s [3] | About 2 h 47 min |
| beehiiv Free, one per contact | 20,000 | 30 per minute [6] | About 11 h 7 min |
| beehiiv Lite, one per contact | 20,000 | 180 per minute [6] | About 1 h 51 min |
| beehiiv Pro, one per contact | 20,000 | 500 per minute [6] | 40 min |
| beehiiv, bulk update of 1,000 | 20 | Plan limit per minute [6][7] | Under a minute of requests; the update runs as a job [7] |
Pacing a bulk job in Make
Make retries the two most common temporary errors, ConnectionError and RateLimitError, automatically, but only if you enable incomplete executions in the scenario settings. [10] Turn that on before any bulk run so a 429 pauses a bundle instead of losing it. The Retry error handler adds your own attempts and intervals on top. [10]
To set the pace rather than react to 429s, cap how many records each run processes, using the trigger module's record limit where it offers one, and set how often the scenario runs. Each cycle commits or rolls back on its own, and the scenario settings set the maximum number of cycles per run, which defaults to 1. [11] Make's scheduler sets how often runs start, with the minimum interval depending on your plan. [12]
A worked pace for MailerLite: if each row does a search and then an update, that is two API calls per row. A run can fire its calls in a burst, so size each run to fit inside one minute's allowance: 50 rows per run is at most 100 calls, under the 120 limit even if they all land in the same minute. [1] With a run every two minutes, the 20,000-row job takes 400 runs, about 800 minutes or 13 hours 20 minutes, which is worth knowing before you promise a client a same-morning finish.
Pacing a bulk job in Pabbly Connect
Pabbly lists a Delay step that postpones the next action for a set duration, an Iterator for looping over arrays, and auto re-execution of failed and skipped steps. [13] It does not count internal apps such as Iterator, Filter and Router as tasks, but each email-platform action that runs is a task. [13]
For a 20,000-contact update, that is 20,000 tasks against a Standard plan allowance of 10,000 a month [13], so either split the job across billing periods or call the platform's batch endpoint through Pabbly's API module [13], one request per 50 MailerLite upserts or 1,000 beehiiv updates. [2][7]
Before you start a bulk run
- Divide your request count by the documented limit to get a minimum run time. [1][3][6]
- Use batch or bulk endpoints where your credential allows: MailerLite batch, beehiiv bulk update, Kit bulk with OAuth. [2][4][7]
- Turn on incomplete executions in Make so rate-limit errors are retried. [10]
- Cap records per run and set the schedule so even a run that fires all its calls inside one minute stays below the limit. [11][12]
- In Pabbly, add a Delay before the email-platform action and turn on auto re-execution. [13]
- Count lookups: a search plus an update is two requests per contact.
- On beehiiv Free, plan around 30 requests a minute, not the 180 the first call may show. [6]
Questions before you decide
What is the MailerLite API rate limit?
MailerLite allows 120 requests per minute globally and 5 per minute for import creation. Above that it returns a 429 error with a Retry-After header giving the seconds to wait.
Is Kit's rate limit higher with OAuth?
Yes. Kit allows 120 requests over a rolling 60 seconds per API key and states a limit of 600 requests using OAuth. Bulk endpoints also require OAuth.
Why does beehiiv's free plan feel slower than its headers suggest?
beehiiv enforces the first request from an idle credential at the default 180 per minute, then applies the plan limit, which is 30 per minute on Free. Set your pace from the plan table.
How do I stop Make from losing records when an API returns 429?
Enable incomplete executions in the scenario settings. Make then retries RateLimitError and ConnectionError automatically, and you can add a Retry error handler with your own attempts and interval.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- MailerLite developer documentation: rate limits Accessed 30 Oct 2026
- MailerLite API: Batching Accessed 30 Oct 2026
- Kit developer docs: API authentication and rate limits Accessed 30 Oct 2026
- Kit developer docs: Bulk and async processing Accessed 30 Oct 2026
- Kit developer docs: Bulk create subscribers Accessed 30 Oct 2026
- beehiiv developer docs: Rate limiting Accessed 30 Oct 2026
- beehiiv developer docs: Bulk update subscriptions Accessed 30 Oct 2026
- Make Apps: Kit (ConvertKit) Accessed 30 Oct 2026
- Make Apps: beehiiv Accessed 30 Oct 2026
- Make Help: Retry error handler Accessed 30 Oct 2026
- Make Help: Scenario execution, cycles and phases Accessed 30 Oct 2026
- Make Help: Schedule a scenario Accessed 30 Oct 2026
- Pabbly Connect pricing and plan features Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.