Alternative backend host

We’re like to be able to specify a different backend host for our InstantSearch queries. Specifically, we’re storing multiple price classes in our search objects, and we need to be able to both alter the query to change price facets to match the price class for the customer class doing the query, as well as eliminating other prices coming back in the resultset, so the browser never sees the other price classes.

We noticed that we can specify another host to the AlgoliaSearchCore arguments, but it’s not clear how to pass that option through, when instantiating an InstantSearch object. The documentation is rather silent on the subject.


I think you may be interested in our secured api key feature. This will allow you to only give certain users access to a specific subset of your data.

Please let me know if this is helpful for you use-case, or if I misunderstood your question.


No, not quite. I’m not trying to prevent them from altering the query, but to ensure that they cannot see certain fields in the resultset, even if they started a debugger in the browser.

If I understand this correctly, you have multiple prices for a record, and want to show only a certain price depending on which user is searching for that record, correct?

To get a bit more context, could you share how your records are structured, and what your current index configuration looks like?

It’s more than just that. We want to ensure that we follow good security practices, in that prices that a customer is not authorized to see never traverse the browser.

Our record structure is almost identical to this (minus prices):

  "eclipse_part_number": "731108",
  "mta_part_number": "540",
  "description": "Trailer Light Kit 20' Harness",
  "extra_description": "",
  "keywords": "RT540 lights",
  "weight": "2.67",
  "status": "STOCK",
  "availability": "9",
  "dealer": "f",
  "vendor_part_number": "",
  "price_line": "REDNEC-A",
  "buy_line": "REDNEC-A",
  "price": {
    "list": "26.75",
    "retail": "22.93"
  "objectID": "731108"

I’m not sure what you’re looking for, in terms of index configuration. “price.retail” is one of our configured facets.

Awesome, thank you. There are a couple ways I think you could go about this;

  • I do still think this could be a good use-case for the secured API key feature. This will not only prevent users from altering the query, but also ensure that they are prevented from ever getting data back from the API that they are not supposed to have access to. In other words, only a specific subset of your data will be retrievable from your index by a given user-group (such a group will only have a specific narrow set of permissions that you decide to grant them).

  • An alternative solution for this might be to create a replica index, which would have certain attributes set to be unretrievable. The primary index could be used for searches by users with full permissions, like admins for example, and the replica index could be exclusively used for searches by users with limited permissions. Because of the different configuration settings you could apply to each index, the query results from each would be uniquely suited for the appropriate user-group. To ensure that this approach be secure, you would want to generate different Search-only API Keys for both the primary and replica indices.

Wouldn’t a replica index double the number of objects we’re storing, potentially pushing us up to the next pricing tier? We’re explicitly trying to be as conservative as possible, both with object allocation, as well as with operations. This is the primary reason we went with an Algolia recommendation to put multiple prices into each index object – to reduce the total number of objects stored.

The more you describe it, it sounds like the secured API key feature might be sufficient for our purposes.

Yes, the replica solution would indeed double your number of records. I do think the secured API key feature is the most promising path forward based on the goals you outlined.

It’s not exactly clear how this would be accomplished using the secured API key. I see that there’s a way to restrict the data to a subset of objects, but not a way to restrict data to a subset of each object. What am I missing?

So you may have to modify the JSON structure of your records slightly; you would have to first put each price into its own attribute.

After doing this, you could generate a secured API key that uses a attributesToRetrieve param to specify only the price attributes that should be viewable to that particular user group.

e.g. something like this:

secured_api_key = client.generate_secured_api_key('search-api-key', {'attributesToRetrieve': ['public_price']})

Please let me know if this is helpful :slight_smile: