Rutter · Rate Limits

Rutter Io Rate Limits

Rutter applies rate limits at the application (client) and connection level to protect both the Rutter platform and the underlying third-party platforms it integrates with (QuickBooks, Shopify, Stripe, etc.). Because many downstream platforms impose their own strict per-account limits, large historical pulls are performed asynchronously and surfaced via webhooks rather than being read synchronously. Specific per-endpoint numeric limits are not published and are not reconciled in this artifact.

Rutter Io Rate Limits is the machine-readable rate-limit profile for Rutter on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring requests and jobs.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Unified API, Accounting, Commerce, Payments, and Rate Limiting.

4 Limits Throttle: 429
Unified APIAccountingCommercePaymentsRate LimitingQuotasThrottling

Limits

Application Request Rate application
requests
see provider documentation
Per-client request rate across all connections; not publicly numeric.
Per-Connection Request Rate connection
requests
see provider documentation
Requests scoped to a single connection access_token.
Downstream Platform Limits connection
requests
bound by underlying platform
QuickBooks, Xero, Shopify, Stripe, etc. each impose their own per-account limits that can throttle Rutter reads/writes.
Initial Sync connection
jobs
asynchronous
Historical backfills run async; completion is signaled via webhook rather than a synchronous response.

Policies

Async Sync via Webhooks
Large historical data pulls are performed asynchronously; clients should wait for sync webhooks before reading full datasets.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor 429 responses and any Retry-After header.
Cursor Pagination
List endpoints are cursor-paginated (next_cursor); page through results rather than requesting large limits.

Sources