CRM API Rate Limits: What Developers Need to Know Before They Build

Every CRM integration starts the same way. You write some code, test it against a sandbox account with a few hundred contacts, and everything works beautifully. Then you push to production, where the account has 50,000 records and three other integrations pulling data at the same time, and suddenly you're drowning in 429 errors.

API rate limits are the silent killer of CRM integrations. They don't show up in feature lists, they're buried deep in developer documentation, and they behave differently across every major platform. If you're building anything that touches a CRM API, you need to understand these limits before you write your first line of code. Not after your sync job crashes at 2am. Let's get into how the major platforms actually enforce their limits, and what you can do to keep things running cleanly.

How the Major CRMs Handle Rate Limits

Here's the annoying part: no two CRM platforms measure rate limits the same way. Some cap requests per second, others use rolling daily windows, and at least one has moved to a token-cost model where different endpoints burn through your budget at different speeds.

HubSpot

HubSpot enforces burst limits of 100 to 190 requests per 10 seconds depending on your plan tier, with daily caps ranging from 250,000 to 1,000,000 requests. But here's what trips most developers up: the CRM Search API has its own separate limit of around 4 to 5 requests per second. If your integration relies heavily on search queries to find and match records, you'll hit that ceiling long before you get anywhere near the general rate limit.

Salesforce

Salesforce uses a rolling 24-hour window with a base of 100,000 daily API requests for Enterprise Edition, plus 1,000 additional requests per user licence. That sounds generous until you realise the pool is shared across REST, SOAP, Bulk, and Connect APIs. Every integration on the account drinks from the same well. On top of that, Salesforce caps concurrent long-running requests at 25 and limits Bulk API to 15,000 batches per day.

Pipedrive

Pipedrive recently overhauled its system entirely. The old model of roughly 80 requests per 2 seconds has been replaced with token-based rate limits, where each endpoint has a different token cost based on how computationally expensive it is. Your company gets a daily token budget that resets every 24 hours, and burst limits still apply on a rolling 2-second window per user.

Attio

Attio takes a much simpler approach. The API allows 100 read requests per second and 25 write requests per second, with no daily cap at all. You won't spend time calculating rolling windows or worrying about shared quota pools across integrations.

The only thing to watch is the score-based rate limiting on the List Records and List Entries endpoints, where complex filter and sort combinations get assigned a complexity score. If a single query scores too high, it gets rejected. If your combined query scores over a 10-second sliding window exceed the threshold, you'll get a 429 with a Retry-After header, same as anywhere else. But for most integrations, the per-second ceiling is high enough that you'll rarely think about it.

A Quick Comparison

None of this tends to surface at the point the platform gets chosen. CRM comparisons weigh features, pricing and usability because that's what buyers ask about, and the API section, where there is one, rarely goes past confirming that a REST API exists.

Whoever ends up building the integration inherits whatever limits came with that decision, so if a platform is still on the shortlist, the developer documentation is worth half an hour before anyone signs anything.

How to Build Integrations That Won't Break

The patterns that keep you out of trouble aren't complicated, but they do need to be baked in from the start.

Use Batch Endpoints Wherever They Exist

HubSpot's batch APIs let you read or write up to 100 records in a single call, and it still only counts as one request against your limit. Salesforce's Bulk API 2.0 handles large data volumes far more efficiently than individual REST calls. If you're looping through records one at a time, you're burning through your budget for no good reason.

Respect the Retry-After Header

When you get a 429 response, the platform will almost always tell you how long to wait. Don't just retry immediately with a fixed delay. Use exponential backoff, and if you're running multiple workers or threads, centralise your rate limiting so they're not all competing for the same quota.

Replace Polling With Webhooks

Every CRM on this list supports webhook subscriptions for common events like contact creation, deal updates, lifecycle stage changes, and property modifications. Each webhook you set up is one fewer recurring API call eating into your daily limit. Push will always beat pull when you're working within tight rate constraints.

Monitor Your Consumption in Real Time

HubSpot, Salesforce, and Pipedrive all return rate limit headers with every API response. Attio does the same. Pipe these into your monitoring stack and set alerts well before you hit the ceiling. Salesforce's /limits endpoint will tell you exactly where you stand at any point during the day.

Build for the Ceiling, Not the Floor

The biggest mistake developers make with CRM API rate limits is treating them as a problem to solve later. By the time you're getting 429 errors in production, you've already got failed syncs, inconsistent data, and unhappy users. And the platforms themselves aren't going to increase your limits just because your integration needs it.

Design your architecture around the tightest constraint you'll face, not the most generous one. That means understanding which endpoints cost the most, which limits are shared across integrations, and where the hidden sub-limits are. Get that right from day one, and your integration will scale without the 2am wake-up calls.