[Solved] REST API: Using the (undocumented) LIKE operator in a Filter?



I’m working on an interface for a project that builds up databases from our survey results, and among other things need to allow searching for Surveys by partial name, depending on a user’s credentials/team. Since there is no documented fuzzy search, I was initially going to keep a mirror of Survey meta-data in sync and allow users to query that, but it needs to be based on a user’s credentials, since they might not have access to all Surveys, and there doesn’t seem to be a documented way to see what Teams a user is on.


I did notice, however, that it’s possible to use a `LIKE` Filter operator (tested it with SurveyObject), which does exactly what I need, but this isn’t in the documentation. Is this an operator I can safely use, or because it isn’t listed in the documentation, is it not intended for public use, and not guaranteed to always work? Is there an alternate way I can accomplish what I’m looking for?


I also found that operators such as <, >, <=, and >= also work, but are missing from the documentation. Are those missing from the documentation intentionally, and not meant to be used? Or can I safely use them and expect them to work in the future under the same API version?



Jesse Werthei asked
    • Jesse, do you do these kinds of projects on the side as well? I could use some help with a custom project. Feel free to email me at mike.miller@primosolutionsllc.com.

    • Hi Mike,

      I’m not currently doing any freelance or side work, but if that changes in the near future, or if I’m able to release any of the project’s component’s open source, I’ll shoot you an email.

      – Jesse

    Best answer


    Hi Jesse, great question!

    In general, the SurveyGizmo team very rarely alters the behavior of our REST API, so even though these filter operators are undocumented, I feel they are relatively safe to use. I double checked this with a member of our Engineering team, just to be sure. They reassured me that our team has taken the necessary steps to ensure application security, and so these extra filter operators being available does not present any sort of concern for our team that may warrant them being removed suddenly.

    The only reason for pause I can see, is that in the small chance our team did make a change to the API/filtering which caused one of these filter operators to break, it is unlikely to be officially supported (addressed and fixed) by our team. Because of that, I might suggest having a plan B available.

    One possible alternate method could be to cache the results of a Survey “GET LIST” API call for each user in lieu of being able to check teams/permissions directly. This would be used in combination with the initial plan you mentioned, keeping a mirror of Survey meta-data. It’s a bit of a roundabout method (and somewhat of a pain to have to implement your own access control), but on the other hand having local copies of this data would lead to better performance than querying the SurveyGizmo API directly for each interaction.

    I hope this helps!

    Nathan - Survey Astronaut answered
      • Hi Nathan,

        Thanks for the thought-out response. I’d like to request that you mention to your Engineering team the possibility of looking into documenting either the `LIKE`, or at least “, `=` as part of the official API. For organizations with a use-case like mine, it would result in significantly less strain on your servers; I think it would be in SurveyGizmo’s best interest as well as in ours:

        While I can take the polling route, to do so effectively and keep an internal, up-to-date access model, I would need to poll Surveys for every user, and if I stuck to the documented API, that would mean I couldn’t use a Greater Than filter to restrict the responses to only those updated after the last poll; I’d need to page through every result for every user, or do so on every request as opposed to polling. Documenting more of the filters, so we users can access them reliably, would therefore make both our lives easier and, I believe, ultimately save resources on your end.

        Alternatively, you could provide a User->Teams and Teams->Survey endpoint that returns relevant SurveyId’s, which would similarly save significant server strain on your end and delays on our end.

        Is it possible to look into this? Thanks!



      Question stats

      • Active
      • Views7207 times
      • Answers1 answer
      • Followers0 followers