What happens when an API hits a rate limit or goes down?

A well built integration expects both. It queues work instead of firing it all at once, backs off and retries when it is throttled, makes writes safe to repeat so a retry does not duplicate records, and alerts a human when something cannot be recovered automatically.

What a rate limit is

A cap on how many requests you may make in a period. Platforms publish them, and they exist so one noisy integration cannot degrade the service for everyone. Exceeding one usually returns an HTTP 429 response rather than an error in your data, which is why a naive script often looks like it worked while silently dropping records.

The limits are specific to each platform and change over time, so build against the vendor's current documentation rather than a number in a blog post. HubSpot, as an example, publishes its limits: private apps are capped at 100 requests per 10 seconds on Free and Starter and 190 per 10 seconds on Professional and Enterprise, with daily caps of 250,000 requests on Free and Starter and 1,000,000 on Professional and Enterprise, and the Search API is limited separately to five requests per second per authentication token. Check the vendor's own page before you design a sync, because those numbers move.

The engineering that keeps it honest

Queue, do not fire. Work goes into a queue processed at a controlled rate, so a bulk import does not exhaust your daily allowance by lunchtime.
Exponential backoff. On a 429 or a timeout, wait, then wait longer, with a cap and a random jitter so retries do not synchronize.
Idempotent writes. Use a stable external identifier so a repeated call updates the existing record instead of creating a second one. Without this, retry logic creates duplicates, which is worse than the original failure.
Dead letter handling. Anything that fails after all retries goes somewhere durable with the original payload and the error, so it can be replayed rather than lost.
Batching. One batched request instead of two hundred single ones is usually the difference between comfortable and throttled.
Alerting. A named human gets told when the failure queue grows or a scheduled job does not run. A silent integration is not a healthy one.

When the API is simply down

Queue and wait. The integration should degrade rather than fail: hold the work, keep accepting new work, and drain the backlog when service returns. What you do not want is a system that drops records during an outage and has no record of having done so. Our approach to reliability is on the custom integrations page, and a real-world example is in our Unific integration FAQ.

What happens when an API hits a rate limit or goes down?

How a well built integration queues, retries, and tells you before data goes missing.

What a rate limit is

The engineering that keeps it honest

When the API is simply down