HubSpot API Rate Limits for Apps Installed in Many Customer Accounts

A HubSpot app listed on the Marketplace can make 110 requests every 10 seconds in each customer account that installs it, and CRM search has a separate limit of five requests per second per account. Private apps get 100 to 250 requests per 10 seconds plus a daily cap that depends on the customer's subscription. For a SaaS company, the number matters less than where it applies. The budget belongs to each customer's HubSpot account, so one large customer can run out while every other install is fine, and HubSpot's certification review counts the errors that follow.

That makes rate limits an operations problem as much as a coding one. Your sync has to pace itself per account, recover from 429 errors without piling up retries, and stay above HubSpot's 95% success rate across every installed account. Appnigma's integration infrastructure gives your engineers a shared foundation for deployment and monitoring of each customer's connections, and its done-for-you integrations service builds and maintains the integration for teams that would rather keep engineers on the product. If you need a native app and listing, see marketplace apps.

Updated October 2026. Checked against HubSpot's API usage guidelines, CRM search guide and certification requirements. This update corrects the Marketplace limit from 100 to 110 requests per 10 seconds and the search limit from four to five per second, removes a per-app daily cap and burst allowance that HubSpot doesn't document, explains that the 5% rule counts all errors rather than only 429s, and removes a customer example that was not based on HubSpot sources.

HubSpot API rate limits by app type

The limit your code lives under depends on how the app is distributed. HubSpot's API usage guidelines say that for an OAuth app distributed through the HubSpot Marketplace, "each HubSpot account that installs your app is limited to 110 requests every 10 seconds." That covers legacy public apps and apps on the 2025.2 and 2026.03 developer platform. Privately distributed apps are limited by the subscription of the account they run in. That group includes legacy private apps and new-platform apps whose distribution setting is private, which HubSpot describes as "a specific set of allowlisted accounts, or a single account at a time."

Two details trip up SaaS teams. First, the API limit increase that a customer can buy "does not increase the limits" of Marketplace OAuth apps, so a customer upgrading their HubSpot plan doesn't give your app more room. Second, the 110 limit is per installing account, so your total traffic grows with your install count while each customer's ceiling stays fixed. With 300 installs, your app can send up to 3,300 requests per second in total, but never more than 11 per second on average into any single customer.

The 10-second window is rolling. HubSpot names that policy TEN_SECONDLY_ROLLING in its 429 responses, so a burst of 110 requests at the start of a window blocks the next request until earlier ones age out. HubSpot doesn't document any burst allowance above the limit, so plan as if 110 is a hard ceiling.

Endpoints with their own limits

Several HubSpot APIs sit outside the 110 per 10 second limit or add stricter limits of their own. HubSpot's usage guidelines name three of them, the associations API, CRM search and GraphQL.

CRM search is "rate limited to five requests per second per account." It is excluded from the 110 count, returns at most 200 records per page and stops at 10,000 results for any query. Paging past 10,000 returns a 400 error, so search can't backfill a large account. Newly updated records "may take a few moments" to appear in results, which matters if you search right after a write. HubSpot states the search limit per account rather than per app, so plan for other integrations in the same customer account searching too.

The associations API has its own budget of 500,000 requests per day on Professional and Enterprise accounts. Its burst limit is 100 requests per 10 seconds on Free and Starter and 150 on Professional and Enterprise. It also takes larger batches than the object APIs, with 1,000 inputs per batch read and 2,000 per batch create.

GraphQL uses points instead of request counts. HubSpot says "the normal burst limits detailed in HubSpot's API usage guidelines are not applicable" to GraphQL queries, and each account gets 500,000 points per rolling minute. Any CRM collection query runs on the search API, though, so it still counts against the five-per-second search limit.

Webhook deliveries cost nothing. The webhooks guide says requests HubSpot sends to your service "will not count against your app's API rate limits." A few APIs are exempt from the 10-second and daily limits altogether, such as certain single send and source code endpoints. HubSpot warns that heavy use of them can still return 5xx errors, which you handle like 429s.

What a 429 response tells you

An app over its limit "will receive a 429 error response for all subsequent API calls," according to the usage guidelines. The response body names the limit in policyName. DAILY means a daily limit, which resets at midnight in the account's time zone setting. TEN_SECONDLY_ROLLING means the burst limit, which clears within seconds. The two need different handling, because retrying a daily limit only adds errors until midnight.

Successful responses tell you how close you are. HubSpot returns X-HubSpot-RateLimit-Max, X-HubSpot-RateLimit-Remaining and X-HubSpot-RateLimit-Interval-Milliseconds for the 10-second window. The daily headers are "not included in the response to API requests authorized using OAuth," so a Marketplace app can't read a daily balance from them. The X-HubSpot-RateLimit-Secondly headers still appear, but HubSpot says that limit "is no longer enforced" and the headers "should be considered deprecated." Search responses carry no rate limit headers at all, which is why search needs its own client-side pacing. HubSpot also doesn't document a Retry-After header on 429 responses, so how long to pause is your decision. A short, capped backoff with some random jitter is a common choice for the 10-second limit. To see usage per app, account admins can open Development, then Monitoring, then API call usage in HubSpot.

Does a high 429 rate cost you HubSpot certification?

It can, and 429s are only part of the count. The usage guidelines say error responses "shouldn't exceed 5% of your total daily requests," and an app listed on the Marketplace "must stay under this 5% limit to be certified." The certification requirements state the same rule as "an average success rate above 95% across all activities." Error responses count against it whatever the status code. HubSpot adds that "some unavoidable or expected errors may be excluded." A 401 from an expired token, a 403 from a missing scope and a 400 from a bad payload all spend the same 5% as a 429.

The certification page also gives its own example of respecting rate limits, "100 inbound requests every 10 seconds per connected HubSpot account." That is lower than the 110 in the usage guidelines, so pacing each account at 100 keeps you inside both pages and leaves 10 requests of headroom for retries.

Here is what 5% means in practice, as arithmetic rather than a benchmark. An app that sends 200,000 requests a day across all installs can absorb fewer than 10,000 errors of every kind combined. One customer account that keeps hitting 429 on a retry loop can spend most of that alone. Losing certification isn't instant. HubSpot's Ecosystem Quality team "will collaborate with you for up to 60 days," and an app that does lose it stays listed "without the certified badge."

Pacing requests per customer account

Staying under HubSpot's 110 per 10 second limit across many installs takes a limiter keyed by the customer's HubSpot account ID, with a separate budget for search. Because HubSpot's 10-second window is rolling, count the requests actually sent in the last 10 seconds. A token bucket that holds 100 tokens and refills at 10 per second looks equivalent, but it can send its full 100 and then another 100 during the same rolling window, about 200 in total. The earlier version of this page made that mistake. The sketch below keeps a sliding window of timestamps instead, at 100 per 10 seconds for standard calls and five per second for search. On a 429 it backs off only for the burst limit. It is a pattern to adapt, not tested production code.

// One sliding window per HubSpot account and limit type.
const LIMITS = {
  standard: {
    max: 100, windowMs: 10000
  }, // headroom under 110 per 10 s
  search: {
    max: 5, windowMs: 1000
  },      // CRM search, five per second
};
const windows = new Map();
async function take(portalId, kind) {
  const {
    max, windowMs
  }
  = LIMITS[kind];
  const key = `${portalId}:${kind}`;
  const sent = windows.get(key) ?? [];
  windows.set(key, sent);
  for (;
    ;
  ) {
    const now = Date.now();
    while (sent.length && now - sent[0] >= windowMs) sent.shift();
    if (sent.length < max) {
      sent.push(now);
      return;
    }
    await new Promise((r) => setTimeout(r, windowMs - (now - sent[0])));
  }
}
async function callHubSpot(portalId, url, init, kind = "standard", attempt = 0) {
  await take(portalId, kind);
  const res = await fetch(url, init);
  if (res.status !== 429 || attempt >= 4) return res;
  const body = await res.clone().json().catch(() => ({
  }));
  if (body.policyName === "DAILY") return res;
  // park this account until its reset
  const waitMs = Math.min(10000, 1000 * 2 ** attempt) + Math.random() * 500;
  await new Promise((r) => setTimeout(r, waitMs));
  return callHubSpot(portalId, url, init, kind, attempt + 1);
}

An in-memory map only works on one process. Once several workers call HubSpot for the same customer, the window has to live in a shared store such as Redis, or each worker spends the full 100 and the account sees several times that. The same goes for job queues. Partition sync jobs by account so a large customer's backfill waits in its own lane instead of delaying every other customer.

Cutting request volume with batch calls, webhooks and caching

Pacing keeps you under the limit. Fewer requests keep you away from it. HubSpot's usage guidelines recommend batch APIs, caching and webhooks, and the arithmetic shows why batch calls come first.

Take a nightly job that updates 20,000 contacts in one customer account, using only documented limits. One request per contact at 110 requests per 10 seconds takes about 30 minutes of that account's full budget, and every other call for the customer queues behind it. The contacts API batch update takes 100 records per request, so the same job is 200 requests, about 18 seconds. Associations go further at up to 2,000 inputs per batch create.

Webhooks replace polling for change detection. HubSpot delivers events in batches that "will be under 100 notifications" per request, and the deliveries don't count against your limit. When 100 contacts change, fetch them with one batch read instead of 100 single reads. Keep the handler fast, because a response slower than five seconds counts as a failure and HubSpot retries it up to 10 times over 24 hours.

Caching handles the calls that repeat. HubSpot's guidelines name object properties, owners and form settings as data to cache rather than request for every job. Property definitions and owner lists change rarely compared with how often a sync reads them, so a cache with a short expiry per account removes them from the hot path.

Mistakes that cause 429s after customers install

These come from HubSpot's documented limits, and each one tends to show up only with real customer volume.

• Sharing one limiter across all customers. One large account then throttles everyone else.
• Running a limiter per worker. Five workers at 100 each send 500 per 10 seconds into one account.
• Counting search inside the 110 budget. Search has its own five-per-second limit and no headers to warn you.
• Using search to backfill. The 10,000-result cap stops the sync partway through a large account.
• Retrying a DAILY 429. It fails until midnight in the customer's time zone and every retry is another error.
• Refreshing tokens only after a 401. HubSpot says a 401 isn't a valid signal to refresh, and each one counts against your 95%.
• Building a token bucket of 100 that refills at 10 per second. It allows about 200 requests in one rolling window.

Who watches rate limits across customer accounts

Rate limits rarely fail in testing. They fail when a large customer installs, runs an import or switches on a new feature, and the errors land in the success rate HubSpot reviews. Someone has to see which customer connection is failing and why. Appnigma's integration infrastructure is built for that. Your team owns the integration code it writes, and in the page's words, "Appnigma provides the infra and monitoring" so you can "monitor each customer's connections, identify issues" and ship fixes through your normal release process. If you would rather hand the work off, Appnigma's done-for-you integrations come with ongoing maintenance. Its marketplace apps service includes "HubSpot listing review and certification support where eligible." For the wider API picture, including date-based versions, see our HubSpot API builder's guide.

Frequently Asked Questions

What is the HubSpot API rate limit?

A Marketplace OAuth app gets 110 requests every 10 seconds per installing account, and HubSpot doesn't publish a daily figure for it. Private apps get 100 to 250 requests per 10 seconds, and their daily cap of 250,000 to 1 million per account depends on the subscription.

Is the HubSpot search API limit four requests per second?

No. HubSpot's search guide now says five requests per second per account, separate from the 110 per 10 second limit. Older pages, including an earlier version of this one, still say four.

Does the 5% error rule only count 429 errors?

No. Certification asks for an average success rate above 95% across all app activity, and every error response counts, including 401, 403 and 400 errors.

Do HubSpot webhooks count against API rate limits?

No. Webhook deliveries from HubSpot to your service don't count against your app's limits, but the API calls you make to fetch the changed records do.

Can Appnigma help us stay within HubSpot's rate limits?

Yes. Appnigma's integration infrastructure provides the infra and monitoring for each customer's connections, and its done-for-you service builds and maintains HubSpot integrations with ongoing maintenance included.

About the author

Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.

Related Articles

• HubSpot API builder's guide for SaaS integrations
• HubSpot webhooks implementation guide
• HubSpot OAuth and scopes reference
• HubSpot API integration guide with code examples
• HubSpot Marketplace complete guide

Sources

1. API usage guidelines and limits, HubSpot Developers
2. Search the CRM, HubSpot Developers
3. Certification requirements, HubSpot Developers
4. Associations and Contacts API, HubSpot Developers
5. Webhooks API, HubSpot Developers
6. Query HubSpot data using GraphQL, HubSpot Developers