The primary purpose of my tests is to ensure that I am interacting with the Spotify web API correctly. Creating a mocked version would defeat that purpose. (The second most important purpose of my tests is to ensure that the JSON is correctly decoded, but I do indeed have truly self-contained unit tests for that purpose that use local JSON files.) How could I ever be sure that the mocked version has the same behavior? Although Spotify has an impressive amount of documentation, I've discovered dozens of examples of unexpected, undocumented behavior. Who knows what else I'm missing. Using a mocked version would make my tests a lot more unreliable; this tradeoff doesn't make much sense to me.
With a little work you can get a pretty dynamic system going.
I don't think you're taking into account the complexity of the Spotify web API. I'm not only making GET requests for data that is more or less the same each time (which could be easily mocked using local JSON files). The player and playlists endpoints require keeping track of, and mutating, an immense amount of state. Future requests then rely on that mutated state.
Although I've already said this, I need to stress it again: The reason why I need to read user input is so that I can go through the authorization process, which cannot be mocked. In other words, the only tests that require user input are the ones that cannot be mocked, and so mocking doesn't even solve the problem that I set out to solve.