List Customer API not working some time


We are using Square Customer API in our application. We have used “ListCustomer” API to get all customers. But some times it is working and some times it gives 500 “INTERNAL_SERVER_ERROR”. Why this is happening? Same API we are calling multiple times and we got different behavior. We have checked the API logs in square and found that for some API calls gives 500 for ListCustomer API. Attached screenshot of API logs for your reference.

:wave: 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:

Additional Documentation

Customers API Overview
Customers API Overview
Customers API Workflows

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.

The 500 “INTERNAL_SERVER_ERROR” typically indicates an issue on Square’s server side. This could be due to a temporary issue with the server or an unexpected condition that the server encountered when trying to process your request. It’s not something that you can control or fix from your end.

However, if you’re frequently encountering this error, it’s recommended to ensure that your API calls are not exceeding Square’s rate limits. If your application sends a high number of requests to Square APIs in a short period of time, Square might temporarily stop processing your requests and return errors.

If the issue persists, it would be best to reach out to Square’s technical support team with the details of your API calls and the error messages you’re receiving. They would be able to provide more specific guidance based on your account and application details.

This answer was reviewed by @Bryan-Square.

When you got this error were you paginating through the results? :slightly_smiling_face:

I was not doing paginating through the results.

What is Square’s rate limits of API?

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. :slightly_smiling_face: