Rate limits

Prepare your Roots integration to operate safely when the production rate-limit contract is published.

See API availability for current API-contract availability.

Current status

Roots has not published rate limits, rate-limit response headers, burst behavior, or retry-after behavior for the UAT or production API.

Do not assume unlimited throughput. Design your client to limit concurrent requests and avoid uncontrolled retries.

Build a controlled client

1. Use bounded concurrency for requests to the same resource or workflow.
2. Queue non-urgent synchronization work.
3. Avoid polling faster than your integration requires.
4. Apply retry logic only after you confirm the production retry contract.
5. Stop retrying when a request has a business error, such as invalid input or missing permission.
6. Keep payment creation separate from generic retry queues until idempotency is confirmed.

Target schema — confirm in API reference

Confirm the following before production launch:

• Request limits by endpoint, company, credential, and environment.
• Burst limits and concurrency limits.
• Rate-limit response status and headers.
• Retry-after behavior.
• Polling guidance for asynchronous resources.
• Allowlisted or elevated limits for approved workloads.

Next steps

• Read Errors for documented error handling.
• Read Idempotency before retrying money-movement operations.
• Use Production readiness to verify operational controls before launch.