Rate limits

Each key has these limits:

Limit	Default	Past it
Requests at the same time	20	429 too_many_concurrent_requests
Requests a minute	120, with bursts of up to 20 at once	429 rate_limited
New leads a minute	60 (each lead in a batch counts)	429 lead_rate_limited

Your organization’s plan also has a limit on requests a minute, across all your keys together (429 rate_limited). Every plan allows at least 120 a minute, so one key at its default can always use its whole limit.

An admin can change a key’s limits in Settings > API. Requests at the same time can be anything from 1 to 50.

“120 a minute with bursts of 20” means you can send 20 requests at once, then about 2 a second after that, up to 120 in any minute.

Past a limit

You get 429 at once, with a Retry-After header: the seconds to wait. We never hold a request in a queue, so a 429 comes back fast and you decide what to do. Wait, then send the same request again (with the same Idempotency-Key for a write; see Safe retries).

Where you stand

Every answer carries:

Header	What it says
RateLimit-Limit	Requests allowed a minute (the tighter of your key’s and your plan’s).
RateLimit-Remaining	How many are left this minute.
RateLimit-Reset	Seconds until the minute starts again.

Tips

• Sending many leads? Use POST /leads/batch (up to 60 in one request, a minute’s worth of new leads). It’s one request toward the per-minute limit, though each lead still counts toward new leads a minute.
• Don’t ask for the same thing in a loop. Use webhooks to hear about changes, and GET /events to catch up.
• Give each system its own key, so one busy system can’t use up another’s limits.