Rate limits for a multi-tenant Appointments app

I run a multi-tenant booking app for Square Appointments sellers — each connects their own account via OAuth, and we add sellers weekly.

The limit is per application, so every new seller eats into the same budget — we now get RATE_LIMITED on Bookings.SearchAvailability about once a day, and it will get worse.

We’ve done the obvious work: caching, de-duping concurrent calls, capped concurrency, backoff with jitter. That buys headroom, not growth.

  1. So: is running several OAuth applications to spread the load an accepted way to scale here, or something you’d rather we didn’t do?

  2. Can we request a higher limit? We’d rather not split across OAuth apps — that forces every seller to re-authorize.

  3. We call SearchAvailability once per team member to find who performs a service. Can we pass all ids in team_member_id_filter.any and read team_member_id from appointment_segments?

Thanks.

Can you provide your application ID, the merchant ID of the square account that owns the application, a couple of 429 timestamps, and a growth forecast to me in a DM? I will do some review on my end before potentially escalating it internally.

  1. Yes you can, but we’ll review the rate limit first since having new sellers onboard to a new app can be painful.
  2. I can’t guarantee a higher limit but I will look into it.
  3. Put all eligible staff IDs in team_member_id_filter.any; each returned availability identifies the selected provider in appointment_segments[].team_member_id. SegmentFilter reference for SearchAvailability API