Updated June 18, 2026 by Sunny Chauhan.

The Marketplace certification rule that surprises the most founders: HubSpot apps must keep 429 errors below 5% of total daily requests across all subscriber accounts. Trip over 5% and certification gets revoked. The rate limit itself isn't generous either, 100 requests per 10 seconds per connected account, and most product teams I've worked with hit it inside their first month of real customer load. Here's the actual limit structure, the 5% rule explained, and the four architectural patterns that keep apps under both ceilings.

Pro Tip

TL;DR HubSpot caps API calls at 100 requests / 10 seconds per connected portal for OAuth apps. Marketplace certification requires you to keep 429 errors below 5% of total daily requests. Three patterns to stay safe: 1/ Token-bucket rate limiter per portal in your client, 2/ Batch endpoints (the CRM batch APIs let you read/write up to 100 records per request), 3/ Webhook-driven architecture instead of polling. Watch for the per-app daily cap (different number, separate counter from per-portal).

HubSpot publishes two rate limits that matter for Marketplace apps:

→ Per-portal limit: 100 requests / 10 seconds (OAuth apps). This is rolling, not bucketed at second boundaries. If you burst 100 requests in 1 second, you have to wait the rest of the 10-second window. This applies separately to every portal your app is connected to.

→ Per-app daily cap. A separate counter that aggregates across all your portals' API calls. The exact daily number depends on your app tier and Hubs your customers have. For most apps it's in the high hundreds of thousands per day.

Two more counters worth knowing:

1/ Search API: 4 requests / second per portal. The search endpoints are stricter than the standard CRM endpoints. If your app uses /crm/v3/objects/contacts/search heavily, you'll hit this before the 100/10s general limit.

2/ Burst credits. HubSpot allows brief bursts above the 100/10s cap if your average is under it over a longer window. This is implicit, not documented, and you shouldn't rely on it. Design as if 100/10s is a hard ceiling.

Marketplace certification checks your app's 429-error rate. The math:

`` 429 error rate = (429 responses / total responses) over a daily window ``

If 5,000 of your 100,000 daily requests get 429s, you're at 5%. Anything above 5% gets your app flagged in certification review. For already-certified apps, sustained breaches can cost you the certification status.

Why HubSpot enforces this: customer experience. If your app is constantly hitting rate limits, two things happen: your app fails silently for customers, and HubSpot's API team sees a noisy neighbor on their infrastructure. The 5% rule pushes apps toward respecting limits and falling back gracefully when they don't.

The practical implication: you can't just retry-on-429-forever and call it good. You have to architect so the 429s are rare in the first place.

The single most useful pattern: every API call goes through a token-bucket limiter in your client code, scoped per portal.

```javascript class PortalRateLimiter { constructor() { this.buckets = new Map(); }

async acquire(portalId) { if (!this.buckets.has(portalId)) { this.buckets.set(portalId, { tokens: 100, lastRefill: Date.now() }); } const bucket = this.buckets.get(portalId);

const now = Date.now(); const elapsed = (now - bucket.lastRefill) / 1000; bucket.tokens = Math.min(100, bucket.tokens + elapsed * 10); bucket.lastRefill = now;

if (bucket.tokens < 1) { const waitMs = ((1 - bucket.tokens) / 10) * 1000; await new Promise(r => setTimeout(r, waitMs)); bucket.tokens = 1; }

bucket.tokens -= 1; } }

const limiter = new PortalRateLimiter();

async function callHubSpot(portalId, ...args) { await limiter.acquire(portalId); return fetch(...args); } ```

Three things this gets you:

1/ Soft cap below the hard 100/10s. The bucket refills at 10 tokens / second, ceiling 100. You never burst above the limit.

2/ Per-portal isolation. Heavy usage on portal A doesn't starve portal B.

3/ Predictable backpressure. When the bucket runs dry, your code waits, doesn't error.

If your app runs across multiple servers (which it should for any real load), move the limiter to Redis. The bucket state lives in Redis; each server's API call increments the same counter. Otherwise per-server limits multiply by server count and you bust the real cap.

HubSpot's CRM API exposes batch read and batch write endpoints that count as 1 request but handle up to 100 records:

→ POST /crm/v3/objects/{objectType}/batch/read (read up to 100 records by ID) → POST /crm/v3/objects/{objectType}/batch/create (create up to 100 records) → POST /crm/v3/objects/{objectType}/batch/update (update up to 100 records) → POST /crm/v3/objects/{objectType}/batch/archive (delete up to 100 records)

If your code is making 100 individual calls to update 100 contacts, you're using 100 of your 100-token bucket. Switch to a batch call and that becomes 1 token. 100x improvement.

I've audited codebases where switching from per-record to batch endpoints dropped daily API consumption by 90% without any user-visible change.

The slowest way to know about a CRM change in HubSpot is to poll. The fastest is to subscribe to a webhook.

Anti-pattern: every 5 minutes, your app polls each portal's contacts modified since the last poll. With 200 customer portals, that's 200 portals × (60/5) polls/hour × 24 hours = 57,600 polls/day. Even at 1 request per poll, you're consuming a significant chunk of your daily cap before any user action.

Pattern: subscribe to contact.propertyChange webhooks. HubSpot pushes events when something changes. Your daily request count drops to near-zero for change detection. The only API calls you make are the ones that fetch the changed records when a webhook fires.

See our HubSpot webhooks implementation guide for the full webhook setup.

Three smaller patterns that compound:

→ Cache CRM schema reads. Object property lists rarely change. Cache them for an hour or a day, not per-call.

→ Batch writes through a queue. Instead of writing immediately on every event, push writes to a queue and have a worker flush in batches every few seconds. Combined with batch endpoints (Pattern 2), this can drop write request volume by 95%+.

→ Defer non-urgent work to off-peak hours. If your app has nightly enrichment jobs, schedule them when the customer's daytime traffic is low. Same daily count, less likely to collide with sync usage that triggers 429s.

You need observability on this before certification. Track:

1/ Total daily API requests per app (across all portals) 2/ Total 429 responses per app per day 3/ Per-portal 429 rate (find the noisy portals) 4/ Per-endpoint 429 rate (find the heavy endpoints, often search)

A simple dashboard with these four metrics tells you whether you're trending toward the 5% line. I'd recommend alerting at 3% as an early warning.

For high-volume apps, also track the per-portal 100/10s headroom. If you regularly use 90 of 100 tokens on the average portal, a small load spike will push you over. Build slack into the limit.

Salesforce ISVs are used to governor limits and the per-org API request limit (which varies by edition but is typically 100K calls per 24 hours for Enterprise Edition). HubSpot's structure differs: per-portal limits are per-10-seconds (much shorter window), and the daily app-level cap is implicit rather than published as a clean number.

The architectural patterns transfer though. At Appnigma, the governor limits we engineer Salesforce 2GP Managed Packages against follow the same principles: respect the limits as hard ceilings, batch wherever possible, use platform events (HubSpot's webhooks equivalent) instead of polling, monitor consumption per-tenant. The vendor specifics differ; the architecture is the same.

• [ ] Client-side rate limiter implemented per portal → Yes / No

• [ ] Rate limiter state shared across servers (Redis or equivalent) → Yes / No

• [ ] Batch endpoints used for any operation touching multiple records → Yes / No

• [ ] Webhooks used instead of polling for change detection → Yes / No

• [ ] CRM schema reads cached → Yes / No

• [ ] Writes queued and batched → Yes / No

• [ ] 429 rate tracked per app per day → Yes / No

• [ ] Alerts set at 3% 429 rate → Yes / No

• [ ] Per-portal 429 rate tracked (find noisy portals) → Yes / No

• [ ] Load-tested against the 100/10s ceiling at realistic peak → Yes / No

A conversation intelligence product (meeting summary syncing to HubSpot deals) was at 12% 429 rate three weeks before their certification submission. Their backend: every meeting summary triggered 4 sync calls to HubSpot (find deal, get current properties, update deal, log activity). With 200 portals each doing 50 meetings a day, that's 40,000 API calls.

Three changes:

1/ Cached the property schema for each portal (12-hour TTL). Cut "get current properties" out of the hot path. -25% calls.

2/ Switched from per-meeting writes to batched writes flushed every 30 seconds. Combined with the batch update endpoint, this dropped write call count by 80%. -60% calls cumulatively.

3/ Added the per-portal token-bucket limiter. The remaining requests were paced under the 100/10s ceiling rather than bursting.

End state: 429 rate at 0.8%. Daily API call volume down from 40,000 to under 8,000. Certification approved.

HubSpot caps OAuth apps at 100 requests / 10 seconds per connected portal, with a separate per-app daily cap that varies by tier (HubSpot API rate limits documentation). Search endpoints have a stricter 4 requests / second per-portal limit.

HubSpot Marketplace certification requires your app to keep 429 (rate-limited) responses below 5% of total daily requests across all subscriber accounts. Apps above 5% can have certification revoked. The rule is explicitly part of the certification requirements.

Retry with exponential backoff, but also fix the underlying cause. The retry alone keeps your app working; the architectural fix (rate limiter, batch endpoints, webhooks) keeps your 429 rate under 5% for certification. Read the Retry-After response header when present.

1 request. A batch read or batch write of up to 100 records consumes a single token in your rate limit budget. This is the single largest optimization for high-volume apps; switching from per-record to batch can cut API consumption by 90%.

Both. The 100/10s limit is per connected portal (each customer's HubSpot account has its own bucket). The daily cap is per-app, summing across all portals. Both must be respected.

Search endpoints (/crm/v3/objects/{type}/search) are limited to 4 requests / second per portal. If your app uses search heavily, it'll hit this before the 100/10s general limit. Cache search results aggressively or precompute.

Track total daily requests per app, 429 responses per day, per-portal 429 rate, and per-endpoint 429 rate. Alert at 3% 429 rate to give yourself room before the 5% cert threshold. For per-portal headroom, track tokens consumed per 10-second window.

Sunny Chauhan is the founder and CEO of Appnigma AI, a no-code platform that generates Salesforce AppExchange-ready Managed Packages from natural-language prompts. He holds Salesforce certifications in Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate. The rate-limit-respecting architecture Appnigma enforces in generated Salesforce Apex (bulkified DML, governor-aware queries, async deferral) maps directly to the HubSpot patterns described above.

Originally published June 18, 2026. Last reviewed June 18, 2026. Rate limit values and certification thresholds verified against HubSpot's API usage documentation and Marketplace certification requirements current as of the published date.

• HubSpot Webhooks Implementation Guide

• HubSpot API Key Management Guide

• HubSpot OAuth and Scopes Complete Reference

• HubSpot Sandbox Setup Guide

• HubSpot Custom Integration Build Guide

• HubSpot Integration Platform Architecture Patterns

1/ HubSpot Developers, API Usage Details and Rate Limits 2/ HubSpot Marketplace Certification Requirements 3/ HubSpot Developers, Batch API Endpoints 4/ HubSpot Developers, Search API Documentation

What's your current 429 rate, and which of the four patterns gives you the biggest near-term drop?