When using Rutter's read endpoints, you will not experience the normal rate-limits imposed by a specific E-commerce platform (e.g. Shopify).
Rutter's write endpoints pass requests directly to their respective E-Commerce and Accounting platforms and will be subject to each platform's unique rate-limits.
How does Rutter resolve rate limit issues?
In order to offer fast performance to merchants' data, Rutter uses a combination of caching and webhooks to store the latest data for a merchant. When you send requests to Rutter's API (Products, Orders, and Customers), most of the time the data will be cached and returned immediately. One exception is when a merchant first authorizes you to use their data: Rutter will begin downloading the data immediately, but it will not be ready until the INITIAL_UPDATE webhook fires.
How does Rutter cache data and keep it up-to-date?
Rutter does an "initial sync" of a merchant's data when they authenticate your app. This may take hours to days depending on the size of the store, and the most requested data will be cached first. Once this process completes, Rutter subscribes to relevant webhooks on the E-commerce platform to keep the data in sync. As a final precaution, Rutter also regularly makes requests to platforms to double-check that no updates were lost from the webhooks.
Why does Rutter not unify rate limits for write endpoints?
To prioritize the speed and responsiveness of these endpoints, Rutter passes write requests directly to their platform. We are currently investigating more uniform ways to handle rate limits in the future.