HubSpot API rate limits by tier: daily caps, the 10 second burst, Search API limits and how to stop 429 errors
10 min read Integration The Adapters team
Last updated August 2026
Field mapping auto-plugged · tap a port to rewire
Plug a source port into
Transform on this cable
JSON in
JSON out
5 sample records ready
Almost every stalled HubSpot integration is stalled for one of two reasons, and neither of them is the daily call limit everybody worries about. It is either the burst ceiling in a 10 second window, or the CRM Search API running at 5 requests per second while the rest of the account sits idle. Here are the current numbers by tier, read from HubSpot documentation on 20 August 2026, and the six changes that actually fix a rate-limited sync.
Key takeaways
- Two limits, not one. A burst limit of 100 or 190 requests per 10 seconds per private app, and a daily total of 250,000 to 1,000,000 calls per account.
- Search has its own ceiling. 5 requests per second, 200 records per page, and a hard cap of 10,000 results for any single query.
- Batch endpoints move 100 records per call. The single largest efficiency gain available, worth up to 100 times fewer calls.
- Daily is per account, burst is per app. Separate private apps isolate the burst limit and make a 429 traceable to one integration.
- Webhooks are free. Deliveries do not consume the API allocation, so replacing a poll with a subscription is pure headroom.
What are the HubSpot API rate limits?
HubSpot enforces two separate limits at once. The burst limit caps requests in any rolling 10 second window: 100 requests for Free and Starter accounts and 190 for Professional and Enterprise, counted per private app. The daily limit caps total calls per account across every private app: 250,000 on Free and Starter, 625,000 on Professional and 1,000,000 on Enterprise. Publicly distributed OAuth apps get 110 requests per 10 seconds per installing account instead.
The distinction matters more than the numbers. The daily allocation is a budget you can plan against, and most accounts never come close to it. The burst limit is a throttle you hit in the first minute of a backfill, and it is the one that returns the 429 responses filling your error log.
HubSpot API rate limits by tier
| Tier or app type | Burst limit | Daily calls | What to know |
|---|---|---|---|
| Free and Starter | 100 per 10 seconds | 250,000 | Per private app for the burst, per account for the daily total |
| Professional | 190 per 10 seconds | 625,000 | Burst raised from 150. The changelog quotes 650,000 daily, the guidelines table 625,000 |
| Enterprise | 190 per 10 seconds | 1,000,000 | Daily allocation doubled from the previous 500,000 |
| With API Limit Increase | 250 per 10 seconds | +1,000,000 per purchase | Purchasable twice. The daily allocation stacks, the burst increase does not |
| Public OAuth apps | 110 per 10 seconds | Set per installing account | Per installing account. The API Limit Increase add-on does not apply to public apps at all |
One inconsistency is worth flagging rather than papering over. HubSpot raised these limits, and the changelog announcing the change quotes 650,000 daily calls for Professional while the current usage guidelines table quotes 625,000. We show the guidelines figure above. Before you size a backfill against either number, check what your own account reports, because 25,000 calls is the difference between a load finishing overnight and stopping at 4 AM.
What is the HubSpot Search API rate limit?
The CRM Search API is limited to 5 requests per second, separately from the general burst limit, and returns at most 200 records per page. Any single query is capped at 10,000 total results, and paging beyond that returns a 400 error instead of more records. These three numbers together explain most HubSpot integrations that feel inexplicably slow.
Five requests per second is roughly a fortieth of the general burst ceiling on a Professional account. An integration that calls Search once per record is therefore running at 5 records per second while 185 requests of headroom sit unused every 10 seconds. The record volume does not have to be large for that to turn a ten minute job into an overnight one.
Endpoint-specific limits worth knowing
| API or object | Limit | Detail |
|---|---|---|
| CRM Search | 5 requests per second | A separate ceiling from the general burst limit. Raised from 4 |
| CRM Search page size | 200 records per response | Raised from 100, which halves the calls needed for any paginated search |
| CRM Search result cap | 10,000 results per query | Paging past it returns a 400 error rather than more records |
| Batch endpoints | 100 records per request | Applies to create, read, update and archive alike |
| Custom event send | 1,250 requests per second | Batches of 500. A much higher ceiling than the CRM APIs |
| Custom event definitions | 500 per account | With 30,000,000 event completions per month |
| Webhook subscriptions | 1,000 per app | Webhook deliveries do not consume the API allocation |
| Private apps | 20 per account | Enough for one app per integration in almost every organization |
What happens when you exceed HubSpot API limits?
HubSpot returns HTTP 429 with a body describing which limit you crossed, and the request does not execute. There is no partial credit and no queue: the call is simply refused, and it is your job to try again later. Crossing the burst limit clears in seconds. Exhausting the daily allocation does not clear until the daily window resets, which means an integration that burns through it at noon is down for the rest of the day.
The failure that costs the most is not the loud one. A 429 with no retry logic behind it often means a batch of records silently never lands, and nothing alerts because the job technically completed. A week later a report is wrong, somebody investigates, and the missing rows turn out to be from a single Tuesday afternoon. Treat the 429 count as a first-class metric and alert on it rising, not just on jobs that crash.
How do you avoid HubSpot rate limits?
Six changes, in the order they pay off. The first two account for most of the improvement in almost every integration we have seen, and both are code changes rather than purchases.
Fix 01
Batch before you optimize anything else
Create, read, update and archive endpoints all accept 100 records per call. A 50,000 record backfill written as single requests is 50,000 calls and will exhaust a Starter account daily allocation on its own. Written as batches it is 500 calls. No other change on this list comes close to that multiple, and it is usually a small change to the code that builds the request body.
Fix 02
Stop calling Search once per record
The pattern that kills HubSpot integrations is looking up each incoming record with a Search call to find its HubSpot ID before writing it. Search is capped at 5 requests per second, so that loop runs at 5 records per second no matter how much headroom the general limit has. Fetch the ID map in bulk with a batch read on a unique property, or hold the mapping in your own store, and search only when you genuinely need a filtered query.
Fix 03
Handle 429 with exponential backoff, not an immediate retry
A 429 response means you crossed the burst ceiling in that 10 second window. Retrying immediately extends the window you are over and turns a two second pause into a sustained failure. Back off exponentially with jitter, respect any Retry-After header, and make the job resumable so a partial batch does not have to start over. Log the 429 count as a metric rather than swallowing it, because a rising count is the earliest warning that volume has outgrown the tier.
Fix 04
Replace polling with webhooks
Polling every five minutes to find the handful of records that changed is how an account spends a daily allocation on nothing. HubSpot webhooks push creation, property change and deletion events to your endpoint, allow 1,000 subscriptions per app, and cost nothing against the API allocation. Keep a nightly reconciliation pass as a safety net, because webhook delivery is not a guarantee, but let the webhooks handle the routine work.
Fix 05
Give every integration its own private app
The daily allocation is shared across the whole account, but the burst limit is per app. Separate apps mean a runaway backfill in one integration cannot starve the others in the same 10 second window, and a 429 tells you immediately which system caused it. Accounts allow 20 private apps, which is more than almost anyone needs. Scope each one narrowly while you are there.
Fix 06
Narrow the query instead of paging deeper
The Search API returns at most 10,000 results for any single query, and asking for page 51 of a 10,000 result set returns a 400 rather than more records. The fix is not deeper pagination, it is a narrower filter. Slice by a date window, usually lastmodifieddate, and walk the windows. This is also what makes a backfill restartable, because a failed window is a window you can rerun.
Can you increase HubSpot API limits?
Yes, through the API Limit Increase add-on, which raises the burst ceiling to 250 requests per 10 seconds and adds 1,000,000 calls to the daily allocation. It can be purchased twice for a total of two million additional daily calls. Two conditions matter: the daily allocation stacks across both purchases while the burst increase does not, and the add-on does not apply to publicly distributed OAuth apps.
Before buying it, work out which limit you are actually hitting. Teams routinely purchase daily headroom to solve a problem that was a burst throttle, or a burst increase to solve a Search API ceiling the add-on does not touch. Log the 429 responses with the limit name HubSpot returns and you will know within a day which one it is. That costs nothing and is the difference between a fix and an invoice.
Do HubSpot webhooks count against the API rate limit?
No. Webhook deliveries are pushed to your endpoint by HubSpot and do not consume your API allocation, which makes them the cheapest source of headroom available. An app can hold up to 1,000 webhook subscriptions covering object creation, property changes and deletions. Replacing a five minute poll with a subscription removes those calls from the budget entirely.
The caveat is that webhook delivery is best effort rather than guaranteed, so a webhook-only design will eventually drift. The pattern that holds up is webhooks for the routine path and a scheduled reconciliation pass, usually nightly, that queries records modified since the last successful run and repairs anything the webhooks missed. That pass is cheap because it is a filtered batch read rather than a full scan.
Does HubSpot count failed API calls against the limit?
Requests that reach HubSpot and are processed count, including ones that return a 400 for a malformed payload or a 404 for a missing record. A request refused with a 429 is not executed, but the attempt that triggered it was. In practice this means a retry loop with no backoff can consume a meaningful share of an allocation producing nothing but errors, which is one more reason the retry strategy matters as much as the request strategy.
Validation failures deserve their own handling. If HubSpot rejects a record because a property value does not match its type or a required association is missing, retrying the identical payload will fail identically forever. Route those to a dead letter store with the offending values attached, and keep the retry path for transient failures only. Email engagement data is a common source of these, particularly in teams whose mail is spread across several providers and needs consolidating into one place before any of it reaches a CRM record cleanly.
How many API calls does a HubSpot sync actually use?
Work it out before you buy anything, because the arithmetic is usually reassuring. A daily sync of 200,000 contacts, batched at 100 records per call, is 2,000 calls for the read and 2,000 for the write. Against a Professional allocation of 625,000 that is under one percent. The same sync written as single requests is 400,000 calls, which is roughly two thirds of the allocation for one job.
This is why the right question on a vendor demo is not how many connectors they have. It is whether the connector batches, whether it searches per record, and how it backs off on a 429. A vendor who cannot answer those three is spending an allocation they do not measure. We keep the full set of limits tabled alongside the platforms that live inside them on HubSpot integration tools.
Where rate limits fit in a working HubSpot integration
Rate limits shape three decisions and are irrelevant to the rest. They decide whether you poll or subscribe, whether you batch or loop, and how you match records on update, because matching is where per-record Search calls sneak in. Everything else about the integration, the property mapping, the conflict rule, the schedule, is unaffected by them.
If the destination is a warehouse rather than another application, the calculus shifts again, because you are reading in bulk on a schedule rather than writing conversationally. The mechanics of that route, including the incremental filter that keeps a nightly load small, are covered in HubSpot to Snowflake and HubSpot to BigQuery. For the reverse direction, pushing warehouse-modeled scores onto HubSpot properties, the limits on this page are the binding constraint and reverse ETL tools covers the trade-offs.
Sync HubSpot without babysitting the rate limiter
Batched reads and writes, backoff on 429s, and per-record error logs you can actually read. Flat from $49 a month, with no task meter and no row counter.
No credit card required.