n8n rate limiting CRM workflows have to respect is not a mystery to be discovered by trial and error in production. A bulk update, an enrichment pass, or a sync job that loops over hundreds of records with no pacing between requests will eventually hit a wall the CRM has published in its own documentation, an exact number of requests per ten seconds and per day, not a vague “too many requests” threshold nobody can plan around.
n8n Rate Limiting CRM Workflows Actually Need to Respect
When a workflow sends requests to a CRM faster than the CRM allows, the CRM’s own API rejects the excess, and n8n surfaces this plainly. Per n8n’s own documentation, “when an n8n node hits a rate limit, it errors,” and specifically, “if n8n received error 429 (too many requests) from the service, the error message is ‘The service is receiving too many requests from you.'” That error is not a bug in the workflow’s logic, it is the CRM correctly enforcing a limit the workflow never checked against in the first place.
A 429 is, in one sense, the better outcome, because it fails loudly and immediately. HubSpot’s own API usage guidelines note a second, quieter failure mode sitting behind the same underlying problem: “a high number of requests may result in 5xx errors,” which “can be addressed the same as you would 429 errors,” but which look, from inside a workflow’s error handling, like the CRM itself is having an outage rather than like the workflow overran its own request budget. A team debugging what looks like intermittent HubSpot downtime is sometimes really debugging a loop with no pacing.
What n8n Actually Gives You to Pace Requests
n8n does not leave pacing as something to build from scratch. Its own documentation describes “two ways to handle rate limits in n8n’s integrations: using the Retry On Fail setting, or using a combination of the Loop Over Items and Wait nodes.” Retry On Fail is the simpler of the two: enabling it on a node means “the node automatically tries the request again if it fails the first time,” and critically, the documentation is specific about how to tune it for rate limits rather than generic transient errors: “set Wait Between Tries (ms) to more than the rate limit. For example, if the API you’re using allows one request per second, set Wait Between Tries (ms) to 1000 to allow a 1 second wait.” Retry On Fail reacts to a rate limit after it has already happened, spacing out the retry rather than the original request.
Loop Over Items combined with a Wait node prevents the rate limit from being hit at all, rather than recovering from it after the fact, which matters most on a genuinely large batch where retrying repeatedly failed requests would add real time to the run even if every retry eventually succeeds. The pattern is to “add the Loop Over Items node before the node that calls the API,” then “add the Wait node after the node that calls the API, and connect it back to the Loop Over Items node,” which paces every request in the batch by design rather than by reacting to a failure.
For any node built on the HTTP Request node specifically, there is a third option that does not require adding separate nodes at all: a built-in Batching option. Per that node’s own documentation, “Items per Batch” lets you “enter the number of input items to include in each batch,” and “Batch Interval” lets you “enter the time to wait between each batch of requests in milliseconds,” which introduces the same kind of pacing the Loop Over Items and Wait combination achieves, configured directly on the node making the calls.
Knowing the Actual Limit Instead of Guessing
The pacing settings above are only useful once a workflow knows what number it is pacing against, and that number is published, not something to reverse-engineer through failed requests. HubSpot’s own guidelines lay out exact figures by tier: Free and Starter accounts get “100 / app” per ten seconds and “250,000 / account” per day; Professional accounts get “190 / app” per ten seconds and “625,000 / account” per day; Enterprise accounts get the same “190 / app” per ten seconds with “1,000,000 / account” per day. A workflow built to stay comfortably under whichever of those figures applies to the account it is running against will not need Retry On Fail to bail it out, because it will never trigger the 429 in the first place.
Publicly distributed apps installed via the HubSpot Marketplace work under a different figure entirely, “each HubSpot account that installs your app is limited to 110 requests every 10 seconds,” excluding the separately-limited CRM Search API, a detail that matters specifically for teams running n8n integrations built as marketplace apps rather than private, account-specific connections. Confirming which limit actually applies, private-app tier limits or the marketplace-app limit, is a five-minute check against the CRM’s own documentation, and it is the check that turns “how many requests can this workflow safely make” from a guess into an exact number.
Turning that number into an actual Batching or Wait configuration is simple arithmetic once the limit is known. A Professional-tier private app’s 190 requests per ten seconds works out to roughly one request every 53 milliseconds at the theoretical ceiling, but pacing a workflow to run flat against that ceiling leaves no headroom for other requests made through the same app credential at the same time, from a manual retry, a webhook firing, or another node in the same workflow. A workflow using the HTTP Request node’s Batching option might set Items per Batch to 20 and Batch Interval to 2000 milliseconds, which works out to roughly 100 requests per ten seconds, comfortably under that app’s own 190 burst limit with room to spare for whatever else uses the same credential. The exact numbers matter less than the habit of deriving them from the account’s actual published tier rather than picking a batch size and interval that felt roughly safe.
Where Teams Get This Wrong
The most common mistake is building a bulk-update or enrichment workflow with no pacing at all, running it once successfully against a small test batch, and assuming it will scale linearly to the full dataset without hitting any limit.
The second common mistake is treating Retry On Fail as sufficient on its own for a genuinely large batch operation. It recovers from individual failed requests, but a workflow that keeps firing requests fast enough to trigger repeated 429s is still spending time retrying rather than completing, when pacing the original requests with Loop Over Items and Wait, or the HTTP Request node’s own Batching option, would have avoided the failures entirely.
The third common mistake is misdiagnosing a batch of 5xx errors as a genuine CRM outage rather than a self-inflicted pacing problem, since HubSpot’s own documentation treats “a high number of requests” resulting in 5xx errors as a distinct, separately-named cause worth addressing the same way as a 429, not as an external service failure to wait out.
The fourth common mistake is pacing a workflow against a guessed or remembered rate-limit figure rather than the account’s actual current tier. Free, Starter, Professional, and Enterprise accounts carry different published numbers, and a workflow built against the wrong one either paces too conservatively for no reason or is not actually safe at all.
The fifth common mistake is assuming a workflow’s own private-app rate limit is the whole picture. HubSpot’s own guidelines are specific that for privately distributed apps, “the burst limit… applies individually per app,” but “the daily limit… is shared across all apps within the same HubSpot account.” A workflow’s ten-second burst pacing only has to account for requests made through that same app credential, but its daily budget is shared with every other private app on the account, so an n8n workflow tuned to stay comfortably under the burst limit on its own can still contribute to the account blowing through its shared daily cap if several integrations are running against the same account at once.
Related Reading
For the wider error-handling discipline this specific pacing problem sits inside, see Advanced n8n Error Handling Strategies for Resilient SaaS Workflows. For the automation build work this applies to directly, see n8n Consultancy. For the CRM foundation these workflows usually write into, see HubSpot Consultancy.
Go deeper: Automating HubSpot Lead Scoring with n8n · Automate HubSpot Contact Deduplication with n8n
Frequently Asked Questions
What happens when an n8n workflow hits a CRM’s API rate limit?
The node errors and n8n surfaces the CRM’s own error message. For a 429 response specifically, n8n’s error message reads “The service is receiving too many requests from you.” This is the CRM correctly enforcing a documented limit, not a fault in n8n itself.
How does n8n pace requests to avoid hitting a rate limit?
Three ways: enabling Retry On Fail with a wait time set above the rate-limit interval, using Loop Over Items combined with a Wait node to pace every request in a batch, or using the HTTP Request node’s own Batching option with Items per Batch and Batch Interval settings.
Are HubSpot’s API rate limits the same for every account?
No. For privately distributed apps, Free and Starter tiers get 100 requests per 10 seconds per app; Professional gets 190 per 10 seconds per app; Enterprise also gets 190 per 10 seconds per app. The 10-second figure applies per app, but the daily figure, 250,000, 625,000, or 1,000,000 depending on tier, is shared across every private app on the same account. Publicly distributed marketplace apps work under a separate 110-requests-per-10-seconds limit per installing account.
Why would a rate-limiting problem look like a CRM outage rather than a workflow issue?
Because a high volume of requests can produce 5xx errors rather than the more obviously self-explanatory 429 response. HubSpot’s own documentation notes these should be addressed the same way as 429 errors, but from inside a workflow’s logs, a burst of 5xx responses can look like the CRM itself is failing rather than like the workflow has outpaced its own request budget.