Spotify's Android SDK, the Redirect URI, and Valid Schemes

Spotify is a very popular audio streaming service, one that long has courted app developers with SDKs and API endpoints. However, their developer offerings keep changing, and their SDKs and documentation do not always keep pace.

One aspect of their setup is the “redirect URI”. Ostensibly, this is for OAuth, but they require it even in places where OAuth is not being used. Of note, they claim that the redirect URI needs to exist and match in three places:

• In the app details that you post to their developer console

• In the value that you pass in various API calls to their SDKs

• For Android apps, in the manifest entry for some activity that will react to SDK call responses, in the form of an <intent-filter>

In February 2025, they posted that they were tightening up the rules surrounding redirect URI values, especially their schemes:

Any redirect URI using HTTP will stop being supported, except loopback IP address literals such as http://127.0.0.1 for IPv4 and http://[::1] for IPv6. Any invalid redirect URIs will need to be changed. You can check them under your client’s ‘settings’ tab in the developer console.

Redirects using a custom scheme will still be supported, but we recommend developers to use HTTPS redirects where possible. For mobile applications, we recommend using Android App Links and iOS Universal Links where possible.

They specifically cite that “com.example://callback can still be used as before”.

However, this does not seem to be the case.

I was experimenting with Spotify integration. Using their latest Android SDK, I was unable to authenticate by any means, including both their auth-lib (what I wanted) and their “built-in auth flow”. When I eventually tried logging in through a Web browser, using AuthorizationClient.openLoginInBrowser(), the browser gave me a plain-text error screen saying that I had an “insecure redirect URI”.

While “insecure redirect URI” did not come up much in searches, the use of “insecure” echoed back to that February blog post. I was using a custom scheme at the time, and I wondered if their blog post was mistaken about Spotify’s support for custom schemes.

As soon as I switched from a custom scheme to https, everything started working.

Note that for auth-lib, at least for the Spotify app-based authentication (AuthorizationClient.openLoginActivity()), you do not need the <intent-filter>, let alone have it configured for an App Link. My guess is that this will be important if you might wind up with authentication via a browser, such as because the Spotify app is not installed or is unavailable for some reason. In my case, simply using https for the redirect URI in the developer console and in my Kotlin code was sufficient.

So, if you are having Spotify integration authentication problems, and you are using a custom scheme, try switching to https — you might have better luck.