Hi @DavidT, I took a look into this and you’re right that the admin URL format changed. The products index now uses savedViewId instead of the old saved_search_id, and the value doesn’t match the IDs returned by productSavedSearches.
productSavedSearches is still fully supported, but the identifier the admin URL now uses isn’t exposed through the public Admin API. There’s no public SavedView query and no documented way to map a SavedSearch ID to the savedViewId in the URL.
I’ve contacted the team that owns the admin index tables internally to check whether any supported deep-link approach exists for saved product views, and I’ll follow up here once I hear back. In the meantime, it would help to know what the deep link does in your app. For example, are you linking merchants from your app into a filtered products view? Thanks for raising this here!
Yes, I allow the user to select a saved view to be used to bulk edit products. I had a button that linked to the view so they could see what products would be edited.
Hey @DavidT , I raised this with the owning team internally and just heard back from them.
They confirmed that savedViewId is currently an internal-only identifier, and that the lack of a supported public deep link to the exact saved product view is the current expected behavior.
productSavedSearches remains supported and returns SavedSearch records, but there is no public SavedView query or documented mapping from a SavedSearch ID to savedViewId.
The team are interested in the use case you outlined however, so they have opened an issue to explore whether public deep linking is something they want to support in the future. I’ll be tracking this myself going forward and will follow up here if there are any material developments worth sharing.