Rate limits

To keep RushHour fast and reliable for everyone, the API limits how often some requests can be made. When you go over a limit, the API answers 429 Too Many Requests instead of processing the request.

Which requests are limited

Limits apply to endpoints that are expensive to run — for example uploading documents, AI-powered features, and some map and address lookups. These limits count requests per user over a short time window, so when one user reaches a limit, other users are not blocked.

The exact numbers are not published and may be adjusted over time. Build your integration so it copes with a 429 from any endpoint.

What a 429 response looks like

• The status code is 429.
• The body is empty — there is no response envelope.
• The response does not say how long to wait.

Nothing was processed, so the request can be sent again once you have waited.

Handling 429 responses

1. Wait, then retry. Start with a short pause, such as one or two seconds.
2. Back off. If the retry gets another 429, double the wait each time, up to a sensible maximum such as a minute.
3. Add jitter. Randomise each wait a little, so several workers don't all retry at the same moment.
4. Give up eventually. After a few attempts, stop and report the failure rather than retrying forever.

The same approach works for 503 Service Unavailable responses.

Staying under the limits

• Spread out bulk work. Process large imports or uploads steadily, rather than sending everything at once from many parallel workers.
• Ask for bigger pages. Fetch lists with a larger itemsPerPage instead of many small pages — see Pagination and filtering.
• Cache what rarely changes. Keep reference data, such as types and settings, instead of requesting it before every call.
• Don't poll faster than you need. If you check for changes on a schedule, choose the longest interval your process can accept — see Webhooks.