Why does Search API filter has a limitation of 100 values with IN operator?

We are migrating away from local copy of hubspot data to present tickets to our users and trying to use API endpoints. I got blocked multiple times by search endpoint limitations and is really a frustrating experience so far.

While using a filter with IN operator, I am limited to an array of 100 values. Splitting the filter/requests and stitching the results afterwards seems like an expensive yet complex process at this point due to our reliance on filter, pagination and sorting. Is there any way to get pass this limitation? I could not find this anywhere in API documentation which would have helped us deter from this path early on.

Hey @hpatilrr - thanks for posting in the Community!
I’d like to tag in some API experts to see if they have any insight on how you may be able to get past this limit. @Ben_M, @franksteiner79, and @alyssamwilie - any thoughts here?
Shane, Senior Community Moderator

Hi @hpatilrr,

Just in case you have not considered this, you could check whether GraphQL would be of help here:

This does not directly address the use case, but for reference, here is a page that lists out some of the API limits and which limits can be increased in general:

Lastly, if GraphQL does not solve for the use case, I would suggest submitting your use case to the HubSpot Developer feedback form: HubSpot Developer Feedback Form

I had to split requests to get past this limitation. I understand benefits of restrictions in a system to maintain performance but they need to be well documented so engineers don’t find out too late in the process.

Hi all,

Just wanted to share a few alternatives that you could consider instead of stitching paginated IN batches:

  1. Invert the query direction: if you’re filtering tickets by an external ID list, consider whether the id list can instead be expressed as a range/BETWEEN or a property-based filter (e.g., a pipeline/status/date filter) that doesn’t require enumerating every value.
  2. Use CRM Search’s own pagination/sorting on a narrower filter, then filter the returned page client-side against your id list, rather than pushing the whole id list into the query.
  3. If this is a bulk/backfill-style sync rather than a live user-facing query, the Imports API or exporting via associations may be a better transport than Search for large ID sets.

I hope this helps!

Bérangère

This post was created with the assistance of AI tools