I haven’t seen anymore of the “ghost” errors that occurred and weren’t logged, but today I did get another seemingly random RATE_LIMIT_ERROR that was logged:
As you can see, there weren’t what I would consider “high rate” messages going on at the time. I’m still a little stumped about why I get these errors sometimes. It doesn’t seem like the recommended retry logic with exponential backoff would help much, because it doesn’t appear I’m actually exceeding any reasonable rate limits when this occurs, but I’m open to suggestions…
There’s not much more that you can do other than retry the call when you get a one off 429 like this. If you’re getting multiple errors in a row then the exponential backoff will need to kick in.
Are you monitoring the QPS’s for all your calls to the Catalog API? We really don’t have a tool to determine if you’re exceeding limits. All we can recommend is that you handle the 429 gracefully.
In the seconds leading up to that 429, my app made no more than 2 queries per second to the Catalog API. Generally, my app never exceeds ~3 queries per second to any endpoint. I know you don’t publish rate limits, but it would be helpful to know if that’s even within the same scope for a rate that would reasonably trigger a RATE_LIMIT_ERROR.
Square does have rate limits but we don’t document the limits. We encourage you to handle the limit gracefully by building a retry mechanism. This mechanism should have an exponential backoff schedule to reduce requests when volume is necessary. Also some randomness wouldn’t hurt to avoid a thundering herd effect.
We would expect developer’s applications to reach a point where they start running into rate limiting in production. The solution for running into the rate limit is our suggestion to exponentially backoff schedule your requests, with randomness to avoid thundering herd effect.
Alternatively, maybe we can talk about what your application is doing, and what API calls are starting to run into a rate limit. Maybe I can make some suggestions on optimizing your implementation of API calls to reduce the number of API calls you are making. Or maybe you should consider webhooks to get information about events as they happens, backed up by polling the APIs less often.
We are the institution that sells digital codes. I have been using your API for about a month. Espacially the catalog API. Before the error , I was working for the adjust stock quantity. The rate limit error is valid, but it should be canceled after a certain time for the developers. I would be very happy if you provide a quick solution. regards.
