Qobuz importer stopped working on release pages

[Deniz8891]

Although I see no issue in artist and label pages (links to corresponding releases in MB still get injected), none of the functionalities on album pages (namely the buttons for showing ISRC and importing the release) appear anymore. Same issue across multiple browsers on Windows PC.

[arsinclair]

Can you provide a link where you're testing?

Also, please paste the contents of the Dev Console, if there's anything relevant.

I'm checking at the moment at https://www.qobuz.com/us-en/album/fujiwarp-01-hiromichi-fujiwara/vulp1p7pxc6vc and it seems to be working for me:

Also, what is the extension version, what browser do you use and what extension for user scripts is installed? (you mentioned multiple browsers but we can focus on one, for example Chrome)

[Deniz8891]

Can you provide a link where you're testing?

It's not on a particular link but my issue appears on any album link: https://www.qobuz.com/{locale}/album/...

Also, please paste the contents of the Dev Console, if there's anything relevant.

I'll post you screenshots of the responses I get on the Dev Console with and without the userscript enabled.

First the version without any userscripts running:

Once I enable the Qobuz importer, this is what I get:

Key difference being the messages for failure to get access to the Qobuz API and get the album data.

Also, what is the extension version, what browser do you use and what extension for user scripts is installed? (you mentioned multiple browsers but we can focus on one, for example Chrome)

I primarily use Firefox. Briefly tested the script on Chrome too and it still didn't work.
Script's version: 2025.12.21.2 (the latest version)
Extension for scripts: Violentmonkey v2.31.0

It might be worth noting that I did my last tests with all other userscripts (installed on Violentmonkey) and all remaining browser extensions disabled.

[arsinclair]

Interesting, Qobuz API returns 404 for you, but not for me.

Are you able to run curl requests? Can you try calling

curl -H "x-app-id: 712109809" "https://www.qobuz.com/api.json/0.2/album/get?album_id=vulp1p7pxc6vc"

and let me know what it returns.

Also, are you behind some kind of proxy? Are you able to maybe use VPN to try different locations, e.g. Germany.

It is possible that they are blocking access for some countries, where Qobuz is not yet present.

[Deniz8891]

After changing my PCs proxy settings to one of the countries where Qobuz is available, the script worked. The console didn't return any 404 message either while trying to parse the API.
On one hand it makes sense considering that Qobuz is unavailable where I come from. I can still view standard album pages ( https://www.qobuz.com/{locale}/album/... ) but not their streaming versions ( open.qobuz.com/album/... ).
On the other hand I was able to use the script fairly recently without even changing my location (didn't travel abroad, nor do I have a running VPN subscription). I even cited it on some of my edits:
Edit #137410849
Edit #136511988

^ Both very region-specific releases, only available in Canada and Japan respectively.

I wonder if there was a change in Qobuz's policies. It reminds me of how Deezer changed their API to return the correct response only if you're in the right location (a change that ruined many of the MB importers that were already being used en masse).

[arsinclair]

It is possible that it's a policy change, but it could also just be a more technical decision: if there's no users in those countries that are paying money, there's no point for the server resources to be spent on serving requests to them. I don't like this decision too, but it at least appears logical.

I see only 3 potential solutions here:

• tell the users of the script to use a VPN/change their location if a 404 is detected at the API request;
• try to see if the userscript could work without an API call: after all the page is rendered for you, so some structured data might already be available somewhere in scope; worst case scenario - fall back to HTML parsing;
• host a tiny proxy somewhere in a supported location and if the endpoint returns 404, route this request through that proxy.

Not sure which one I like more, №3 is the most neat, but whoever owns the proxy will have some visibility over what goes throught it. №2 is the most effort-intensive. №1 is not really solving the problem, but moving it onto users' shoulders.