Search API

Copy
GET http://recs.richrelevance.com/rrserver/api/find/v1/<API_KEY> or GET http://integration.richrelevance.com/rrserver/api/find/v1/<API_KEY>

Note: If you are making the Search API requests directly from the web browsers, then you are advised to upgrade the API endpoint to our new First party data capture domain https://recs.algorecs.com in place of https://recs.richrelevance.com. Please work with your algonomy consultant to configure the click URLs to also point to https://recs.algorecs.com.

Returns product results for a search term. This is the main API to initiate search requests. You can specify multiple parameters such as number of products to return, page number, filters to apply, etc to refine the search request further.

The response is a list of product information and facets needed to render a search results page. It could change based on search attributes settings available on FIND dashboard. (See below for more details on the response object).

When using the Search API for autocomplete as product suggestions, “instant search,” or “inline search,” the following parameters must be included to ensure optimal performance:

  • findCallType=overlay

  • facet.enabled=false

  • ngramSearch=true

  • fl=linkId, name, imageId, … (limit to only the necessary fields for rendering product suggestions)

  • rows= (set to the exact number of products to be displayed)

Filter Query (fq)

  • Applies to: GET and POST Find calls

  • Format: Solr filter query syntax with special character encoding

  • Limitations:

    • GET requests have a length limit; use POST for large fq values

    • Maximum of 1000 boolean clauses in any Solr request

Key differences from filter parameter

  • The filter parameter allows basic filtering.

  • The fq parameter supports rich filtering with complex boolean logic, including nested AND/OR conditions.

  • Special characters must be encoded using a custom encoding scheme (see below).

  • For complex filters, prefer the POST method to avoid exceeding URL length limits.

  • Avoid excessive use of fq to maintain optimal API performance.

  • There is a limit of 1000 boolean clauses in any Solr request.

Special character encoding in fq

Because the fq parameter uses Solr syntax, field names with special characters (like spaces) must be encoded.

  • Encoding format: Same numeric code as URL encoding, but use $ instead of %

  • Example:

    • Original field: Womens Sizes

    • URL encoded: Womens%20Sizes

    • fq encoded: Womens$20Sizes

Example usage

Basic fq clause:

Copy
fq=(Womens$20Sizes:"4")OR(Womens$20Sizes:"5.5")
fq=(Womens$20Sizes:%224%22)OR(Womens$20Sizes:%225.5%22)

Note: $20 (representing space) remains unchanged in the URL-encoded version of the fq value.

Date filtering with fq

When using the fq parameter for filtering date ranges, it's important to structure your query in a way that supports effective caching and avoids performance degradation.

Avoid the below pattern:

fq=date:[* TO NOW]

  • Why it's bad: NOW is evaluated down to the millisecond, making it a constantly changing value.

  • Consequence: This prevents caching and leads to inefficient query performance.

  • Workaround: If millisecond precision is truly needed, consider using cache=false.

Recommended patterns

Use rounded time units (like day or hour) for more efficient and cacheable queries.

fq=date:[* TO NOW/DAY+1DAY]

  • Good: Rounds NOW to the current day and adds one day.

  • Cache-friendly: Query changes only once per day.

fq=date:[* TO NOW/HOUR+1HOUR]

  • Good: Rounds NOW to the current hour and adds one hour.

  • Cache-friendly: Query updates hourly, ideal for most time-based use cases.

Note: Using NOW/DAY or NOW/HOUR ensures that your filters are more stable and efficiently cacheable, improving overall performance for frequently run queries.