What is the official API rate limit for the Square API? I cannot find it on an official Square documentation page. I found this on Stack Overflow, but I rather get something more concrete. Thanks!
Unfortunately we currently do not publicly disclose the rate limits at this time. Typically we recommend an exponential backoff algorithm to be put to use in order to overcome rate limit errors if you do encounter them.
1 Like
Hiđź‘‹
Do you currently have any information related to the Square API rate limits?
At this time we currently do not publicly disclose the rate limits at this time. 
I am working on an application myself and was hoping to tackle the rate limit situation. Any help with the exponential backoff algorithm.
What language are you using? There are a lot of examples if you search exponential backoff algorithm with the language your using. 
I am using Flutter. I got a package to do that. Thanks.
If you don’t publicly disclose the rate limits, do you privately disclose that info if we contact you? I am more concerned about my account being blocked if our program keeps hitting the rate limits and the Square system thinks we are suspicious. Would that be a problem?
At this time we don’t disclose the limits. If you follow our guidance on how to handle rate limits you’ll be just fine.
- 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.
Is there a reason Square doesn’t recommend using the RetryConfiguration as exposed by ApiMatic?
Hi,
Understood that I should add a retry mechanism and surely I will do that, but I’m looking for a safe minimum QPS as a start in our batch design. For example, is it OK if I make no more than 3 requests per second? (of course our application will retry just in case occasionally only 2 requests in some second triggered the rate limit)
At this time we don’t disclose the limits but if that’s where you’d like to start you can.
Some feedback for the team: not disclosing rate limits is a big blocker for any kind of professional development against the API. Developers use rate limits to understand what the expected usage and limits (obvs) are of the services they integrate with. Not having disclosed rate limits tells me that I should not build anything meaningful with the API since I have no way of knowing what kind of load it can support.
I was considering building (and open sourcing) an app that can be used to track product spoilage for restaurants / food retailers, since this functionality is not supported by Square. But now I know that I shouldn’t spend time on it since I have no way of knowing if it will perform - in this example, when multiple employees are using an interface to type-ahead search for products to log as spoiled.
Consider this competitor example which clearly outlines the global & per-endpoint limits as well as what headers to expect. Modern platforms that cater to developers also include this functionality by default as part of their SDKs.
PMs feel free to ping me if you’d like to chat about it 
Thanks for taking the time to share your concerns – we totally get why knowing fixed rate-limit numbers up front feels important when you’re planning a new integration. We actually choose not to publish hard-coded limits for two main reasons:
- Security and reliability.
• If an attacker knows exactly where to aim their traffic, they can craft a denial-of-service or resource-exhaustion attack that’s tuned just below published thresholds.
• By keeping our ceilings adaptive, we can detect and mitigate abnormal traffic bursts without giving would-be abusers a precise playbook. - Operational flexibility.
• As usage patterns evolve, we sometimes need to adjust per-endpoint or global throughput—publishing static numbers would force us into a cycle of “announce change → get questions → re-document,” slowing down both fixes and improvements.
That said, we strongly believe you shouldn’t have to fly blind. Here are some concrete steps you can take to discover and respect our limits dynamically, and to build a rock-solid integration:
- Inspect the rate-limit headers on every response.
• X-RateLimit-Limit → the current allowance
• X-RateLimit-Remaining → the number of requests you have left in this window
• X-RateLimit-Reset → when the window will roll over (usually a Unix timestamp) - Implement client-side throttling with exponential backoff and jitter.
• On receiving a 429 “Too Many Requests,” back off (e.g. wait 2^n × 100 ms plus a random jitter) before retrying.
• If you see X-RateLimit-Remaining drop to zero, pause any new calls until X-RateLimit-Reset. - Do a ramp-up experiment.
• Pick a low QPS (queries-per-second) baseline—say, 1–5 QPS—and measure success vs. 429 rates.
• Gradually increase your parallelism or QPS until you start to see occasional 429s.
• Dial back to a level that never triggers limits more than once in a while, and treat that as your “steady state.” - Optimize your traffic pattern.
• Cache frequently requested product lookups locally for a few minutes if possible.
• Batch small reads or writes into logical groups to reduce round-trips.
• Debounce type-ahead or autofill searches on the client side to avoid firing a request on every keystroke. - Plan for bursty or high-volume use cases.
• If you really need sustained higher throughput for a particular endpoint, drop us a note via your Square account manager or support channel. We’re happy to discuss custom arrangements for enterprise-scale partners.
By using these patterns, you’ll be able to “self-discover” the sweet spot for your app without relying on a published static number—and you’ll automatically adapt if we ever shift limits to keep the platform healthy. 
I totally understand the need for operational flexibility, but it comes at a cost to developer experience – that’s a lot of work to do especially for small business customers that don’t staff dev teams.
Should I be getting rate limit response headers from the API? I don’t see any currently.
In any case, great product and thanks for the thoughtful reply!