Deezer GraphQL API | Music Assistant | Page 1

worldly flicker Feb 16, 2026, 1:22 PM

#

Hello there. I hope I am in the right section here. I have been reverse-engineering Deezer's internal GraphQL API while working on mood flows (PR #3171). Turns out introspection is enabled and auth just reuses the ARL cookie we already have.

It opens up audiobooks, live radio, word-by-word lyrics, collaborative playlists, and richer recommendations. None of which are possible with deezer-python.

Longer term it could actually even fully replace deezer-python. It has the same coverage, plus batch queries and actual type safety instead of needing to use getattr() everywhere.

Re stability concerns: yes, it's not officially documented. But that is also the case for the gw_client.py that we are already using for some functionalities. Besides, introspection gives us the full schema, which is effectively self-documentation. And this is the API that Deezer's own web app, desktop client, and shaker.deezer.com all depend on.

Would there be interest in a new gql_client.py that starts with the new features and then eventually in the future gradually takes over?

thorn yew Feb 17, 2026, 9:18 AM

#

Sure! Sounds good. Also make sure to add yourself to the list of maintainers for the deezer provider in the manifest file

worldly flicker Feb 17, 2026, 11:27 AM

#

Thanks! One tooling question before I start: The "ARD Audiothek" provider uses gql with raw string queries, which means query results come back as dict[str, Any] and we have no autocomplete, no mypy. And everything will look similar to the current deezer-python approach.

But since we have the full introspected schema, we could also use ariadne-codegen to generate typed dataclasses and the client itself from the .graphql query files. It's a dev-only dependency (not runtime), and the generated code is just plain dataclasses that get committed to the repo.

Would that be acceptable, or do you prefer keeping it consistent with ARD's gql-only approach?

thorn yew Feb 17, 2026, 11:37 AM

#

If possible to make the code neater, more maintainable it is always preferred to do so.
Adding the actual dataclasses (and maybe a script to generate them) is always better than guessing keys in a free format dict. But I think that should then live in a library and then you can also add some tests for it etc.
You would just work with the library which exposes a public api towards MA and the models as dataclasses.

worldly flicker Feb 17, 2026, 11:54 AM

#

Alright. That sounds good. So that library would then probably be a new repo ("deezer-python-gql"?), that lives under the MA org?

thorn yew Feb 17, 2026, 12:10 PM

#

Yeah, or add it to the existing deezer lib if possible
the lib may be hosted in our org or on your own, that is your call

worldly flicker Feb 17, 2026, 1:27 PM

#

Since it would be a complete replacement that has nothing in common with the current deezer-python fork, I would vote for a new repository within the MA org.

thorn yew Feb 17, 2026, 1:36 PM

#

Sure - just let us know the name and we will set up the repo and add with write access

worldly flicker Feb 17, 2026, 6:54 PM

#

🙏

#

I would go with the name deezer-python-gql to emphasize that it's an alternative to the deezer-python-async library.

thorn yew Feb 17, 2026, 9:26 PM

#

check. what is your Github handle ?

worldly flicker Feb 17, 2026, 9:27 PM

#

https://github.com/jdaberkow

GitHub

jdaberkow - Overview

jdaberkow has 11 repositories available. Follow their code on GitHub.

thorn yew Feb 17, 2026, 9:31 PM

#

You should have an invite now
and write/maintain access to https://github.com/music-assistant/deezer-python-gql

worldly flicker Feb 17, 2026, 9:50 PM

#

Perfect. That should do it. Thanks!

thorn yew Feb 17, 2026, 10:14 PM

#

Well thank you for putting so much effort into this! 💪👍

worldly flicker May 17, 2026, 5:53 PM

#

So. After all I finally reached a state I am happy with.

#

https://github.com/music-assistant/server/pull/3900

#Deezer GraphQL API