A quick question about Scoped Search Keys: We have the requirement for some collections being available in their entirety to all users. So we are generating a general Search Key creating a scoped search key (used for expiration right now only). Now, there is a need that an additional collection is added. For that one collection (and only that), we need to restrict access to certain documents only. This should be done through a field

userId

and a scoped key with that filter. If we understood the concepts correctly, there is no option to create just one key fulfilling that requirement. Simply since not all collections would have the

userId

field (those which are available to all users) and the search on these with that generated scoped key would just yield 0. So are we indeed required to deal with multiple scoped key per user and decide which one to use based on the query? How do we tackle that best?

A scoped search key is essentially a normal Search‑Only key plus a cryptographically‑signed bundle of search parameters (most commonly a

filter_by

clause). Whatever you embed in that bundle is applied to every search that uses the key and the user can’t override it. • If you embed

filter_by: userId:=123

, the filter will run against all collections referred to by that key. • Any document (or whole collection) that doesn’t have a

userId

field simply fails the filter and never surfaces, so your “public” collections would appear empty. Because of that, one key cannot simultaneously say “give me every record in collections A, B, C but only a subset of collection D”. You need a way to apply the filter only when you hit the sensitive collection. Since the multi search request supports API key for each sub-request, you can create 2 API keys, one with the embedded filter and one without and just issue 2 requests like this:

POST /multi_search
X-TYPESENSE-API-KEY: scopedPublic
{
  "searches": [
    {
      "collection": "articles_public",
      "q": "kubernetes",
      "query_by": "title,body"
      // will inherit the top‑level key (scopedPublic)
    },
    {
      "collection": "restricted_docs",
      "q": "kubernetes",
      "query_by": "title,body",
      "x-typesense-api-key": "scopedPrivate"   // ONLY this search carries the user filter
    }
  ]
}

Okay, so this necessarily would need us to ensure multiple keys per user are leveraged and used according to the target collection / scope. That helps us in making decisions on how to move forward. Much appreciated!

Hello 🙂 I am facing the same question. In our case, we would have a good use of the multi search on our « top result page » of our search, which mixes different contents. We also have dedicated tabs for each content type. We have 6 different types of content With this in mind, would it be better that we generate 6 scoped keys when the user enters the search, or would it be better to do front -> back -> typesense and add the filter_by in the backend? This second option feels a bit less good as it gives less flexibility on the frontend-side

6 scoped search keys should be fine. Scoped keys are not even server generated, it just embeds a filter_by clause as a digest onto a public search api key, and is a fully client side operation.