Hi, Hoping someone might be able to point me in the right direction. Just started looking at the delivery api and was wondering if it would be possible to have dynamic indexing of properties and also have dynamic filtering? Use case is that I want to be able to filter on document type props without having to update the code every time a new filter type is added. Mostly because I may not be maintaining it long term. I think I gotten halfway there by matching on a regex pattern in the query e.g. @"tag_(.+?):(.+)" == tag_myProp:propValue This can be used in the CanHandle method as well as the BuildFilterOption. The other part though is the indexing, but that needs to be fairly specific when creating IndexFieldValue and IndexFile in the GetFieldValues and GetFields methods. I was hoping to have somewhere to define what props should be indexed in a place that doesn't require a deployment (perhaps a top level node?), which might be possible in the GetFieldValues method because there is a IContent parameter returned in the method call, but GetFields doesn't return any parameters. I think I might be barking up the wrong tree and trying to fit a square peg into a round hole, but I feel that I am close to getting something functional, and am struggling with best practice. Just looking for some advice from others who have successfully used the content delivery api. Just as a note, I don't think there will be a huge amount of nodes to search, so maybe using the content delivery api is overkill? I am perhaps thinking of something more akin to graphql? Thanks.

Did you get this sorted out in some way? I am also struggling with custom filter and how to get my nested properties indexed. Wrote a post on this today.

I've managed to get it working, but I think it might be poor practice. I don't like that I needed to use the IContent provided in the parameters to go and fetch the IPublishedContent version because IContent doesn't have the same property editor mappers and just gives the raw data.