An integration works perfectly in testing with ten records and breaks in production with ten thousand: the API returns 'too many requests', the workflow errors out, and half the records are updated and half are not. Rate limits are a fact of every API. Integrations that respect them are not slower in practice; they are the ones that finish.

Know the limits

Every API documents requests per second, per minute or per day, and often separate limits per endpoint. Read them. HubSpot, Salesforce, Zoho and the enrichment providers all differ, and they change. Build the limit into the workflow as a configuration value, not a guess.

Batch where the API allows

Most CRMs accept batch create and update calls — a hundred records in one request instead of a hundred requests. Use them for bulk work. For single-record real-time work, a queue with a worker that pulls at the allowed rate keeps within limits without dropping anything.

Retry with backoff

On a limit or a transient error, wait and retry — a second, then two, then four, with a cap and a maximum attempt count. Respect the retry-after header when provided. Log the retries; a rising retry rate is an early warning that volume is outgrowing the plan or the design.

Make writes safe to repeat

A retry after a timeout might repeat a write that actually succeeded. Use idempotency keys where the API supports them, and where it does not, check before creating — search by email or external ID, then create or update. Duplicates from retries are the most common data-quality bug in CRM integrations and the easiest to prevent.