Reference guide
HubSpot API rate limits and 429 errors
A practical reference for teams deciding how quickly an integration can call HubSpot, what a 429 response means, and where queues, backoff, and workflow throttling fit.
Fact-checked against official HubSpot sources · Last verified 17 August 2026
Current HubSpot API limits
HubSpot applies burst and, for private apps, daily request limits. The exact allowance depends on the app type, HubSpot subscription, and any purchased API limit increase. CRM Search endpoints have separate limits and are excluded from the general OAuth burst figure.
Use these figures for planning, then confirm the connected account's current allowance in HubSpot's API usage screen before setting production queue rates.
| App or account type | Burst limit | Published daily limit |
|---|---|---|
| Marketplace OAuth app using the latest limits | 110 requests per 10 seconds per installed account | No general daily limit stated on the usage-guidelines page |
| Private app · Free or Starter | 100 requests per 10 seconds | 250,000 requests per day |
| Private app · Professional | 190 requests per 10 seconds | 625,000 in developer guidance; 650,000 in the product catalogue |
| Private app · Enterprise | 190 requests per 10 seconds | 1,000,000 requests per day |
| Private app with one API limit increase | 250 requests per 10 seconds | 1,000,000 requests per day |
What a HubSpot 429 error means
HTTP 429 means the caller has crossed a rate limit. HubSpot identifies these responses with the RATE_LIMIT category and may include a policyName such as daily or ten-secondly-rolling. Read the response body and rate-limit headers rather than treating every 429 as the same failure.
A 429 should normally be retried, but not immediately in a tight loop. Honour Retry-After when it is present, pause the affected queue, and resume with exponential backoff plus jitter. Keep idempotency in mind so a retried write cannot create a duplicate or repeat a side effect.
- Log the endpoint, account, app, policyName, correlation ID, and retry delay.
- Queue requests per connected HubSpot account; one busy customer should not block every other account.
- Reserve capacity for interactive or urgent work instead of running continuously at the published ceiling.
- Alert on a rising 429 rate before the integration enters a long retry backlog.
HubSpot retries and your integration retries are different
HubSpot can retry certain workflow actions. Its error-handling documentation says custom code actions automatically retry 429 and 5xx responses for up to three days, beginning after one minute and reaching a maximum eight-hour gap. HubSpot's webhook workflow action also retries failed requests and honours Retry-After.
Those platform retries protect a HubSpot-triggered action. They do not replace rate limiting in a separate integration that calls the HubSpot API. The calling integration still needs its own per-account queue, backoff, concurrency control, and idempotent writes.
Choose the control based on traffic direction
For external integration → HubSpot API traffic, enforce the limit in the calling client or worker. For HubSpot workflow → external API traffic, place a pacing step before the sensitive workflow action. Daeda Throttle is designed for the second direction.
When several HubSpot workflows call the same provider, their traffic must share one combined queue. Separate delays or separate per-workflow limits can still exceed the provider's account-wide allowance when the workflows release together.
Official sources
Limits and platform behaviour can change. These primary sources were checked on 17 August 2026.
- HubSpot developer usage guidelines — Burst limits, private-app daily limits, 429 fields, headers, and certification guidance.
- HubSpot API error handling — 429 responses, Retry-After, custom code retries, and workflow webhook retries.
- HubSpot product and services catalogue — Published account-level product entitlements and API limits.
