These are there to stop a loop, not to be planned around. Ten reads a second, kept up, is more than a sync job needs. A route counted against one of the smaller budgets says so on its page.
What is counted for the store
A few requests make Shoply send something: an email to a buyer, or a request to your own server. A few more read a great deal: a finance report reads every order of a period. Those have a limit that is the store’s or the order’s, shared by the dashboard and every key the store has.The Customer API
Its routes are counted for the buyer’s token, and the two that sign a buyer in for the address that asks. The Customer API guide has every number.Where a key stands
Every answer to a request that was counted says, in its headers:What is counted
Every request a key makes, whatever the answer: one refused for a permission the key lacks, or for a store that is not its own, is counted like one that worked. The one exception is a request from an address the key does not accept. That is counted against the address it came from, not against the key, so somebody trying a key they found cannot use up the budget of the server it was made for. After a run of those the address is turned away for a few minutes.When it runs out
The answer is429 with the code rate_limited, and a Retry-After header: how many seconds to wait. Wait that long and carry on.
Requests sent while a key is being refused are counted too, so a client that keeps on through a 429 waits longer than one that stops.
Staying well inside it
- Ask for a list a page at a time with the largest
perPagethe route takes, not a row at a time. - Use webhooks to hear of an order being paid, instead of asking.
- Keep what does not change often: a store’s products change when you change them.

