I am getting this when I am doing bulk upserts of products. We are doing 200 in a batch. It looks like some get uploaded then this error starts coming up. Can someone please provide some direction on how to resolve this?
I’m Square Dev AI, here to help answer your question!
Based on the information you’ve provided, the following documentation will help answer your question:
https://developer.squareup.com/docs/squarebridge/business-central/onboard
https://developer.squareup.com/docs/catalog-api/update-catalog-objects
Additional Documentation
Work with Images
https://developer.squareup.com/docs/orders-api/quick-start/step-3
https://developer.squareup.com/docs/build-basics/handling-errors
If this documentation helped you find a solution, please check the box indicating that this reply solves the problem.
Otherwise one of our Developer Advocates will provide additional assistance shortly.
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.
Thank you. Can you point me in documentation on how to catch that exception? I assume if a batch causes that exception, the whole batch would have not inserted and I can just re-try that batch again?
Of course! Here is our Error handling documentation. 
Thank you, but I am looking for some documentation where I can catch the error and get the “wait time” and then allow to run the same batch. I can’t get access to any of the status/Retry-After data without catching an exception?
Are you using one of our SDKs?
Yes. Version 20.1.0 for .NET
Okay, we don’t have documentation on the wait time. The Square .NET SDK includes built-in rate limiting features to help developers handle API request rate limits. Here are the default values for the relevant configuration settings:
BackoffFactor: The default backoff factor is 2. This means that the wait time between retries will be doubled each time a retry occurs.RetryInterval: The default retry interval is 1 second. This is the initial amount of time to wait before the first retry attempt.StatusCodesToRetry: By default, the SDK will retry on HTTP status codes 429 (Too Many Requests), 503 (Service Unavailable), and 500 (Internal Server Error).MaximumRetryWaitTime: The default maximum retry wait time is 60 seconds. This is the maximum amount of time that the SDK will wait before making a retry attempt.
To handle the “Too Many Requests” (429) error, you can indeed focus on setting the numberOfRetries configuration option, which determines how many times the SDK will retry a request that has failed due to rate limiting. By setting this value, you can control how aggressively your application retries requests.
However, it’s important to note that while setting numberOfRetries can help manage rate limits, you should also consider the other settings to ensure that your retry strategy is effective and does not create additional load on the system. For instance, having a reasonable BackoffFactor and MaximumRetryWaitTime can prevent your application from retrying too quickly and potentially exacerbating the rate limiting issue.
Thank you! I assume since this is async, it will wait and retry in the background? I ask because I am just curious 
Yes, that is correct.
I am not seeing which SDK object these properties are part of? Thanks in advance!
I am not seeing which SDK object these properties are part of? Thanks in advance!
What is it that your exactly looking for? If your using the SDK we take care of the rate limiting and retires for you. There isn’t anything additional you need to do.
I am sorry. I am looking for the object I would hook on to
like .BackoffFactor
With the SDK there isn’t. The SDK handles this for you. You just need to call our APIs with the SDK like normal and it will handle this for you.