How to Get a Qobuz App ID and Secret: What Qobuz API Access Actually Requires

You get a Qobuz app ID and secret by asking for one. Qobuz has a partner-only API: you email Qobuz for an app_id and secret, and approval is not guaranteed. Access requires a partnership application where you submit your use case, and the approval process can take several weeks depending on that use case. The credential is a scheduling problem as much as a technical one.

That changes what a product team should plan. The question is not how fast you can paste credentials into your config. It is what you build while the request sits, and what you ship if the answer comes back no.

Two things surprise teams after approval. Qobuz issues app credentials plus a per-listener token, not one service key that reaches a library. And the operational layer that usually ships with a modern API (rate limit headers, webhooks, an SDK) is not part of the package. Both are below, with the alternative route at the end.

The credentials, side by side

What you hold	Where it comes from	What it reaches
App ID and secret	Issued during developer registration, after an email request Qobuz may decline	Public catalogue endpoints such as search and album lookup
User auth token	An auth flow you run per listener, producing a user auth token	That listener's playlists, favorites and listening history
MusicAPI integrationUserUUID	One hosted redirect, returned base64 encoded on your callback	The same listener's Qobuz playlists, library and profile, on one schema

App credentials reach the catalogue, not the listener

App-level authentication uses an App ID and secret pair issued during developer registration, and those credentials authenticate your application itself and grant access to public catalog endpoints like search and album lookup. That is the half most teams picture when they search for a Qobuz app ID and secret.

The other half is per listener. To read user-specific data such as playlists, favorites and listening history, you guide the user through an auth flow that produces a user auth token, and that token rides on every request to a protected endpoint. If your feature is an onboarding import, a migration or a cross-service library view, this is the path that matters, and it scales per user, not per app.

Plan for the lifecycle, not the first call. Qobuz tokens expire, and the refresh mechanism requires careful handling to avoid dropping user sessions. Rotation, revocation and recovery after a failed refresh outlive the sprint that ships the feature. Our write-up on OAuth and token management across streaming services covers the pattern that repeats once per provider.

Requesting Qobuz API access

The request starts with an email to Qobuz for an app_id and secret, and approval is not guaranteed. Treat it as a partnership application: you submit your use case, and the review can take several weeks. Two consequences land on your roadmap before you write a line of code.

First, you cannot size the integration from public reading. Access requires partnership approval, and documentation is shared directly with approved developers rather than published on a public developer portal. The details of paging, error shapes and field coverage arrive with the decision, not before it.

Second, your ceiling is set by the arrangement, not by a dashboard. Rate limiting on the Qobuz API is enforced per app credential, the exact limits are communicated during developer onboarding, and they vary by partnership tier.

What to cover in the request

Answer the things that set your terms later:

• The use case, concretely. One paragraph on what your product does and which Qobuz data makes it work. The review runs on this, and the timeline depends on it.
• Read, write, or both. Reading a listener's playlists and writing playlists back into their account are different asks.
• Stream URLs or metadata only. Streaming endpoints are heavily restricted and require specific partnership agreements, so asking for audio puts your request in a different category than asking for metadata and playlist operations.
• Volume, as a number. Limits are per app credential and vary by tier, so "production scale" tells a reviewer nothing.
• Markets. Qobuz operates in approximately 25 markets, primarily in Europe, North America, Australia, and parts of Asia. Say where your listeners are.
• Token handling. Where the secret lives, how per-listener tokens are stored, what happens on revocation.

What approval does not hand you

Approval gets you credentials and documentation. The engineering underneath stays yours.

No rate limit headers. Qobuz communicates limits during onboarding but does not include limit metadata in response headers, so you track request counts client-side. Your backoff cannot read the ceiling off a response. It has to model it, per credential, across every worker that talks to Qobuz.

No events. Qobuz requires polling for updates rather than pushing changes via webhooks. When a listener edits a playlist in the Qobuz app, your copy is stale until the next poll. Choose that interval against the per-credential rate limit, because the two budgets compete for the same requests.

No SDK. The API is REST and returns JSON, so any language with HTTP capabilities works, and there is no official SDK. You write the client, the retry layer, the pagination loop and the tests.

Regional behaviour. Qobuz operates in specific markets, and API behavior including catalog availability, streaming rights and format options varies by region. A track your matcher resolves for one listener can be missing for another.

If Qobuz is one row on a roadmap that also names Spotify, Apple Music and Tidal, every item above repeats per provider, with a different review, a different token lifetime and different 429 behaviour each time. That is the work MusicAPI removes: it holds the provider OAuth clients and runs refresh, returns one normalised playlist and track shape across services, and gives you standardised 429s with Retry-After, retries and idempotency built in.

Qobuz Connect is a different door

If you ship a playback device rather than an app, the Qobuz program you want may not be the API at all. Qobuz Connect lets users stream and control their music directly from the Qobuz app on their smartphone, tablet, or computer to compatible hi-fi equipment. It launched in May 2025, and as of Qobuz's December 2025 announcement it was integrated with more than 100 partners across hi-fi brands, multiroom OS platforms, and advanced network/SDK integrations. In that December 2025 announcement, the top five brands by streaming volume were WiiM, Marantz, Denon, Naim, and Eversolo.

Qobuz publishes the list of integrated and compatible brands on its own site, and a device that does not appear on that list is not integrated or compatible with Qobuz. Owners of unlisted devices are pointed at software such as Audirvana or Roon to stream to their hi-fi gear instead. For a brand that is on the list but not working, support goes to the manufacturer, not to Qobuz.

So there are two separate questions. Device playback is a Connect question. Reading and writing a listener's library is a credential question, and that is the one the rest of this post answers.

Reading a Qobuz library without holding Qobuz credentials

The second path skips the review entirely. MusicAPI holds the Qobuz credentials and uses them solely to facilitate music transfers a listener has authorised, the same model FreeYourMusic has run for ten years. You never register a Qobuz app, never store a Qobuz token, and never block a release on an approval date.

The flow is one redirect. Send the listener to the hosted Qobuz authorisation page with a whitelisted return URL:

https://app.musicapi.com/you/qobuz/auth
?returnUrl=https://you.example/connected

The return URL gets a data64 query parameter holding base64 encoded JSON, which you decode on your server:

{
  "integrationUserUUID": "6a002d4b-f95b-471f-a27d-609a42e10cdb",
  "authModel": { "status": "success", "error": null },
  "integration": { "type": "qobuz" }
}

The integrationUserUUID is the id of this connected account, and you store it next to your own user. It is a secret, so keep it server side. From there, one authenticated GET returns the playlists this listener owns and follows on Qobuz:

curl "https://api.musicapi.com/api/6a002d4b-f95b-471f-a27d-609a42e10cdb/playlists" \
  -u "$MUSICAPI_CLIENT_ID:$MUSICAPI_CLIENT_SECRET"

{
  "results": [
    {
      "id": "3124567890",
      "name": "Road trip",
      "totalItems": 42,
      "imageUrl": "https://images.example.com/road-trip.jpg",
      "isOwner": true
    }
  ],
  "nextParam": "eyJvZmZzZXQiOjUwfQ==",
  "totalItems": 87
}

Paging is cursor style. A nextParam that is not null means there is another page, and you send it back as the nextParam query parameter. The same loop drains a long library without per-provider offset quirks. Track level reads follow the same addressing, documented on the Qobuz get playlist tracks endpoint and the Qobuz get user playlists endpoint.

Two details matter for Qobuz specifically. Classical metadata (composer, work, movement) is preserved on read and used to improve match confidence, which is the difference between a usable transfer and a pile of unmatched movements. And when you need a field that is not normalised, passthrough returns the underlying Qobuz token for listeners who authorised a transfer.

Cost and timeline for the alternative

Sandbox keys are free and instant, and authenticating a real Qobuz account and making a first live call takes about an hour. A production integration typically lands in two to four engineering weeks, and it covers the other supported services too, not Qobuz alone.

Billing is per request made to a music service: EUR 0.60 per 1,000 for the first 5M, EUR 0.45 up to 25M, EUR 0.30 above that. The EUR 500 per month minimum applies to accounts on MusicAPI's managed integrations, which is the route this post describes, where MusicAPI holds the Qobuz credentials. An account that runs on its own developer apps pays the metered charge alone. The sandbox is a sandbox, not a trial and not a free tier, and production usage is metered from the first call. The pricing page carries the current buckets.

If the answer is no, or not yet

Three outcomes, and only one of them is blocked.

Approved, and Qobuz is your only service: build direct. You own the client, the polling loop and the per-credential rate budget, and you get the raw field set.

Still waiting: ship the feature against the hosted flow now and keep the direct integration as an option. The listener experience does not change while a review runs.

Declined: direct access is closed, and the transfer route is not, because the credentials involved are not yours to be granted. That is the practical reason this path exists.

For the wider picture on what Qobuz exposes, see our Qobuz API guide to hi-res metadata and playlists and the Napster and Qobuz developer guide for how the niche services compare on access.

FAQ

Can I reuse an app ID issued to another application?

Credentials are issued during developer registration and authenticate your application itself, and rate limiting is enforced per app credential with limits that vary by partnership tier. Running on someone else's pair means running on a ceiling and a tier you cannot see, cannot measure and cannot ask to change.

Does the Qobuz API return ISRCs and hi-res fields?

Yes. Response payloads contain standard fields including title, artist, album art, duration and ISRC, plus Qobuz-specific fields like maximum_bit_depth, maximum_sampling_rate, and hires_streamable. That is the data to key your matching on.

Can I get the raw Qobuz response through MusicAPI?

Yes, for the listeners who authorised a transfer. Passthrough hands you that listener's underlying token when your flow needs a field the normalised schema does not carry.

Does the Qobuz API give me audio?

Streaming endpoints are heavily restricted and require specific partnership agreements. Most teams use the API for metadata, playlist management and catalogue browsing instead.

Skip months of OAuth and per-provider SDK work. Sandbox keys are free and instant, and one API moves libraries between the 11 streaming services MusicAPI supports. Start on the Qobuz API page, or go straight to the MusicAPI Core quickstart and read a real Qobuz library today.