Why is Square dashboard logging GET /v2/catalog/list?types=TAX,SERVICE_CHARGE when my app never calls it?

Questions
1

I’m seeing this in the Square dashboard logs:

  • GET /v2/catalog/list?types=TAX,SERVICE_CHARGE

  • 403 INSUFFICIENT_SCOPES

My React Native app does not call catalog/list anywhere in the code. The only Square-related path is using mobile-payments-sdk-react-native and calling authorize(…) during login/setup.

Questions:

  • Is GET /v2/catalog/list?types=TAX,SERVICE_CHARGE expected to be called internally by the Square SDK?

  • Why would Square log this call even though my app never directly requests it?

  • What is the exact purpose of this catalog endpoint in the SDK flow?

  • How should I fix the 403 INSUFFICIENT_SCOPES error?

Any insight would be appreciated.

WhatsApp Image 2026-05-06 at 11.04.32 AM
WhatsApp Image 2026-05-06 at 11.04.32 AM1600×747 75.1 KB

2

@Snowy No, the Square SDKs are not expected to call this endpoint. If you’re seeing these logs they may be coming from outside of your app. Could you check the User Agent from the Summary tab in your screenshot and see if you recognize where the request came from?

3

I reviewed our native initialization code. We simply call MobilePaymentsSdk.initialize(applicationId, application). There are no custom API calls whatsoever in our Native Module, yet the catalog sync appears in the logs the moment this built-in method is fired.

I asked an AI Agent for verification after isolating the initialization code, and it gave this response:

"There is absolutely nothing custom in this file calling any APIs. All this code does is take your Application ID and pass it directly to MobilePaymentsSdk.initialize() — which is a native method written by Square.

This is the ultimate proof you can give them. You are calling their exact initialization method and nothing else, and that method is what triggers the /v2/catalog/list background sync."

So, could you please recheck this behavior with Square Android SDK v2.3.4? Because we are not seeing any catalog API call on the iOS side.

4

Hi @Snowy , I checked in with the team and we recently made a change around surcharges where we would see this behavior. I suspect why you’re seeing this in Android and not iOS is that your login state there (which is persisted) does not have the right scopes but does in iOS. To confirm, can you try calling .deauthorize() to get a new token and see if the errors persist?

5

@rsata That 403 error was resolved after adding the ITEMS_READ permission during authorization. But I was wondering why this Catalog API is being called even though we are not using it. Right now it’s returning 200 with an empty response. Is that normal, or is there any way to prevent this API call?

Also, on iOS I’m using a slightly older SDK, so could that be the reason there are no logs?

6

@Snowy it’s to pre-load some catalog information on login rather than during other critical parts of the payments flow. Yes, that is normal!