I’m currently working on migrating our integration from XML-RPC to the REST API ahead of the upcoming deprecation. However, I’ve identified a critical blocker regarding the ability to search by custom fields.
Specifically, we heavily rely on the following XML-RPC call: $account_infusionsoft->data()->findByField("ProductCategory", 1,0,'CategoryDisplayName',$CategoryName,array("Id","CategoryDisplayName","ParentId","CategoryOrder"));
After reviewing the official documentation for both REST v1 and v2, there appears to be no equivalent endpoint or parameter that allows for searching/filtering records via custom fields in the same way.
This is a deal-breaker for our migration. We have hundreds of active calls using this function to power sophisticated RFM (Recency, Frequency, Monetary) matrices. Without a functional replacement in the REST API, we cannot complete the transition.
Is there a workaround currently available, or is this feature on the immediate roadmap before the XML-RPC services are fully decommissioned? This needs to be addressed to avoid significant service disruption.
Users have been requesting this functionality since 2022. How is it possible that a CRM still doesn’t allow searching by custom fields?
For my clients, who rely on advanced integrations, this becomes a serious limitation and a potential reason to leave the platform.
RFM matrices, cascading tag logic, syncing data from parent records to child records — all of these workflows become extremely difficult or even impossible without the ability to query custom fields.
You should really consider a local copy of the data for some of what you want to do.
It’s not just a function of whether the API has endpoints to support these high-level functions, it’s a question of how many API calls it will consume, latency, and scaling. If you sync the data down to an RDB under your own control you can build queries or even SP’s that accomplish all of this, while not impacting your API as heavily, running much more quickly, and being more capable of pivoting to future needs.
Also if at some point you do need to switch or even diversify platforms, your local data store can accommodate that more fluidly since your business logic wouldn’t be tied to a particular provider’s unique API.
PS: And if you DO implement a local data store, don’t blindly copy the way Keap has done it. Make it work for your needs, and transform the Keap data as you’re doing your intake. Otherwise it’ll be more painful to pin your implementation to the limitations of Keap’s model in the situations where it doesn’t perfectly match your business.
@Massimo_Romanello - There are workaround solutions posted in the replies to other posts, like using the Saved Search. As David mentioned a local copy is helpful, but it may not be a perfect solution.
@David_Bullock There are pros and cons of doing that. The pros are that having local data would be faster look up times, plus being able to cross reference the data. The cons is that the data may not be up to date. There maybe scenarios where a custom field gets set, but it may need to be immediately looked up. If the data is being synced up every hour or so, then the immediate look up approach will not work, unless you put in fallbacks. Plus you have to build the mechanism to store the data. There is a lot more work involved going down that route.
@OmarAlmonte - I know you are avoiding replying to these requests. I need to point out that your competitors, eg: ActiveCampaign, GoHighLevel, HubSpot, Salesforce, Zoho can all do Custom Field Querying. By not supporting this in the REST v2 you are virtually going backwards with the API. As that feature has been around in XML-RPC for nearly 20 years then why is it a problem now? Or do you want your customers to leave Keap?