The Qobuz API is partner only. There is no public developer portal, no self-serve key and no published endpoint reference: Qobuz routes integration requests to a partnerships address, and getting an app_id and secret means emailing them and waiting. Most of what is hard about a Qobuz project follows from that one fact. This post covers how access works today, what the Qobuz read and write surfaces return, the two edges that cost teams the most time (ISRC search and page size), and which page to open for each task.
Qobuz API access is a partnership, not a signup
Qobuz does not run a developer portal. Its partnerships page is written for hardware makers and media partners: "Manufacturers: Integrate Qobuz with your products. Contact our partnerships for more informations! [email protected]". That address is the front door. There is no application form with a status page, no published review time, and no public reference to evaluate before you commit engineering time.
Stated plainly: "Qobuz has a partner-only API. You must email Qobuz for an app_id and secret, and approval is not guaranteed". Two unknowns go into your plan: whether you get credentials, and when.
If you want the direct route, how to get a Qobuz App ID and secret covers what that request involves. The other route is to call Qobuz through MusicAPI, which holds the Qobuz credentials and serves them on the same request and response shape as ten other services. It is "a transfer layer, not a general-purpose proxy": it exists to move a listener's own library on their behalf, not to resell the Qobuz catalogue.
What Qobuz supports, in one table
| Capability on Qobuz | Status |
|---|---|
| Create a playlist and add tracks | Supported |
| Update playlist name and description | Supported |
| Remove tracks from a playlist or liked tracks | Supported |
| Read library albums | Supported |
| Read followed artists | Supported |
| Search by ISRC | Not supported |
| Returns ISRC on tracks | Supported |
| Max page size (limitParam) | 500 |
| Tracks per playlist | 1,000 |
That is MusicAPI's capability set on Qobuz for a connected listener, from the services and features table, which is generated from the same service metadata the API uses, so it moves when Qobuz moves. "Creating a playlist and adding tracks work on every live service", and update playlists means rename plus description.
Two rows decide most Qobuz work.
Qobuz returns ISRCs and will not search by one
Qobuz tracks come back carrying an isrc, which helps a transfer out of Qobuz when the destination carries one too: "Matching across services is better when both sides have it". The reverse direction is the problem. The user search endpoint accepts an isrc only on services that support it, and Qobuz is not one of them. When Qobuz is the destination, you cannot hand it an identifier and get a deterministic hit. You match on text.
Text matching into Qobuz is less grim than it sounds, for one reason: the catalogue carries real classical metadata, and it survives the read. "Classical metadata (composer, work, movement) is preserved on read and used to improve match confidence". A recording of a Mahler symphony is exactly the item that defeats title plus artist matching, because the artist field might hold the orchestra, the conductor or the composer depending on which service you read it from.
Building this yourself means a title normalizer (remaster tags, live suffixes, feature credits), an artist resolver, a scoring function and a threshold you tune per service. The search endpoint does it in one call and hands back a score: "Resolve any track, album or artist to its Qobuz ID by normalised text, with a confidence score". Items under the threshold are reported, not silently dropped. For the theory, read working with ISRCs, track IDs and cross-platform matching.
Qobuz pages 500 items at a time
500 is the highest page size of any service in the table. "Page size max: the highest limitParam the service takes. A higher value is cut to this", so asking for 1000 gives you 500 and the next page, not an error. Write the loop against the paging data you get back, never against a count you assumed.
Playlists cap at 1,000 tracks on Qobuz, where "Tracks per playlist: the service's own cap on playlist length". If the source playlist is longer, you split it before the write and you pick the naming scheme.
This is where per-provider work becomes obvious. Apple Music pages 25 items at a time, Tidal 20, Amazon Music 100, Qobuz 500. Playlist caps differ, ISRC search support differs, and each service wants its own OAuth client and its own refresh handling. MusicAPI removes that layer: one key covers all 11 services, the provider OAuth clients and token refresh sit on our side, and adding the next service is a change to one string in the request.
Connecting a listener and reading their library
Qobuz auth through MusicAPI is one redirect. You send the listener to the hosted authorisation page with a returnUrl whitelisted in the dashboard, and they come back with base64 JSON carrying an integrationUserUUID. The flow is documented in start sign-in.
GET https://app.musicapi.com/you/qobuz/auth?returnUrl=https://you.example/connected
The callback payload:
{
"integrationUserUUID": "6a002d4b-f95b-471f-a27d-609a42e10cdb",
"authModel": { "status": "success", "error": null },
"integration": { "type": "qobuz" }
}
"Public catalogue routes need no listener auth; user routes are addressed by the userUUID returned from the auth callback". That single UUID reaches the listener's playlists, liked tracks and profile on Qobuz:
GET https://api.musicapi.com/api/6a002d4b-f95b-471f-a27d-609a42e10cdb/playlists
Authorization: Basic <clientId:clientSecret>
The rest of the read surface uses the same addressing: /api/{userUUID}/liked/tracks for Qobuz favorite tracks, /api/{userUUID}/users/profile for the Qobuz listener profile, and /api/{userUUID}/playlists/{playlistId}/items to "fetch all tracks and items from a specific playlist on Qobuz". Parameter detail lives on the get playlist tracks on Qobuz and get user playlists on Qobuz pages.
Writing a playlist to Qobuz
A playlist write is a POST, and the new playlist "is initially empty and can be populated with tracks using our add tracks endpoint".
POST /api/{userUUID}/playlists
Content-Type: application/json
{
"name": "Viva Loca New",
"description": "Description of your playlist",
"visibility": "public"
}
The response is the created playlist:
{
"name": "Viva Loca New",
"id": "1",
"totalItems": 0,
"imageUrl": "https://www.example-image.com/978263478234",
"dateAdded": "2024-10-16T07:52:07.000Z",
"isOwner": true
}
Only name is required. description is optional and visibility takes public or private. The full parameter list is on the create playlist on Qobuz page.
Moving a library into Qobuz
The order of operations for an import is fixed by the two edges above. Read the source library in pages. Resolve each item to a Qobuz ID by normalised text, because ISRC search is unavailable on Qobuz. Create the destination playlist, then append in batches that stay under the 1,000 track cap. Keep a per item record of what matched, what scored low and what did not resolve, because that report is the only honest answer you can give a user whose playlist arrived 40 tracks shorter. How to migrate playlists between streaming services using a REST API walks the same sequence end to end.
Errors you will meet
Two codes carry most of the traffic.
418 with internalCode: 15 means the capability does not exist on that service: "A call that a service does not support answers 418 with internalCode: 15 (NotSupportedMethod)". On Qobuz you will not see it for playlist writes or library reads, but you will see it if you send an isrc to the user search. Treat 418 as a routing decision in your code, never as something to retry.
429 means slow down. MusicAPI answers with "Standardised 429s with Retry-After, retries and idempotency built in", so your client reads the header instead of guessing a backoff curve. The behaviour is documented under rate limits and errors.
Where Qobuz sits next to the other services
Qobuz is one of 11 live services on one schema. The neighbours matter when you scope a transfer feature. Napster is not one of them: "Napster is no longer supported. Napster closed its music streaming service in January 2026", and Resso is listed as no longer available. If a roadmap or a service picker in your product still names either, fix it now.
For the other hi-fi catalogue, read Tidal API in 2026. For the service with no playlist rename and a 25 item page size, see the Apple Music API page.
FAQ
Can I get the raw Qobuz response through MusicAPI?
Yes, for listeners who authorised a transfer. "Passthrough gives you that listener's underlying Qobuz token when your transfer flow needs a field we don't normalise". Use it when you need a Qobuz field that the normalised shape does not carry.
Is there a Qobuz SDK to install?
No. There is no SDK on either side of this: it is plain HTTP from any language, with "One OAuth flow, one schema, no service-specific SDKs".
Can I search the Qobuz catalogue without a connected listener?
Catalogue routes need no listener auth. The services those routes cover are their own list: "The catalog endpoints (no connected user) cover their own list of services. Ask the API for the live list" with GET /public/search/introspection. Read the live response before you depend on a given source being there.
What does Qobuz access cost through MusicAPI?
Billing is metered on requests made to a music service: "€0.60 per 1,000 for the first 5M, €0.45 up to 25M, €0.30 above that". Current buckets and terms are on pricing.
How long does a Qobuz integration take?
"A sandbox key is instant and reading a live library takes about an hour. Production integrations typically land in two to four engineering weeks". The direct route adds the partner approval wait, which nobody can schedule.
Skip months of OAuth and per-provider SDK work. Sandbox keys are free and instant, and one API moves libraries between 11 streaming services. Start on the Qobuz API page.