Operators

For every field, you can add an operator to match the content of that field in a particular way.

📘

Note

When null is used as a value with an operator, the query ignores the matching. For example, exist:null is ignored.

The currently supported operators are:

• match – Optimized for returning the most relevant results and applying common text-matching techniques. It works on searchable string fields, which are fields that should contain large chunks of text. It returns more relevant results than contains and returns more results in general, which offers a better user experience for site visitors. You should use the match operator as a default operator for site search.
• contains – Performs a full-text search on a word or phrase, with support for language stemming when you add the locale parameter. It matches on terms that are tokenized by word boundaries according to UAX #29: Unicode Text Segmentation. This means that when matching on a term with a leading or trailing punctuation character in a term, these characters are ignored. It is the recommended operator when doing full-text search.
• eq – Matches an exact literal value, but the value is case-insensitive, but results matching cases are ranked higher.
• notEq – Retrieves results not matching with an exact literal (but case-insensitive) value.
• gt – Retrieves results with matches that have a value that is greater than the value.
• gte – Retrieves results with matches that have a value that is greater than or equal to the value.
• lt – Retrieves results with matches with a value of less than the value.
• lte – Retrieves results with matches with a value of less than or equal to to the value.
• exist – Matches results that have this field with a value.
• startsWith – Retrieves matches that start with a certain value (prefix). It is case-insensitive.
  Example: startsWith: "eng" will match with "English" or "english", but also "engineering".
• endsWith – Retrieves matches that end with a certain value (suffix). It is case-insensitive.
  Example: endsWith: "lish" will match with "English" or "bullish".
• in – Matches with one or more exact literal (case-sensitive) values in a list.
  Example: in: ["word1", "word2", "this is a phrase"]
• notIn – Returns results that do not match with one or more exact literal (case-sensitive) values in a list.
  Example: notIn: ["word1", "word2", "this is a phrase"]
• like – Matches substrings with wildcard support. Example: % to match on 0 or more characters, _ to match on any character.

🚧

Important

For fields with the type SearchableStringFilterInput, leading wildcards only match on the whole value (alphanumeric string or single token) when wrapped with both a leading and trailing % character. So, it does not match on a prefix within a word.

Leading with only wildcards is not supported at the beginning of a whole value (like a single word and sentence) and results in an error. However, leading wildcards are supported for words within a sentence, not phrases.

Examples:

• like: "%app%" – Will only match with whole words like "app", "applications", "apple", "apples", and so on. It will also match phrases like "Optimizely apps are the most awesome!".
• like: "Course %ollaboration Mad% Simple" – A sentence with a leading wildcard for a word within it, and will match on "Course Collaboration Made Simple".
• like: "%ears" – A leading wildcard with a single word and results in an error.
• like: "%Course Collaboration Mad% Simple" – A sentence starting with a leading wildcard and results in an error.
• like: "%_ourse %ollaboration Mad% Simple%"– A phrase containing a leading wildcard in a word and results in an error.

For fields with the type StringFilterInput, matching (on a substring) with a leading wildcard is supported.

Examples:

• like: "%pp%" – Matches on "app", "applications", "whopper", and so on.
• like: "%ears" – Matches on "ears", "bears", "years", and so on.