Type in your question below and we'll check to see what answers we can find...
Loading article...
Submitting...
If you couldn't find any answers in the previous step then we need to post your question in the community and wait for someone to respond. You'll be notified when that happens.
Simply add some detail to your question and refine the title if needed, choose the relevant category, then post.
Before we can post your question we need you to quickly make an account (or sign in if you already have one).
Don't worry - it's quick and painless! Just click below, and once you're logged in we'll bring you right back here and post your question. We'll remember what you've already typed in so you won't have to do it again.
Please see below the most popular frequently asked questions.
Loading article...
Loading faqs...
Please see below the current ongoing issues which are under investigation.
Loading issue...
Loading ongoing issues...
Hello!
I'm a developer from the rspotify library, a Rust wrapper for the Spotify Web API. I also worked on tekore a bit, which is another wrapper but written in Python.
The issue I'm facing at rspotify is that to run tests that require OAuth automatically (with GitHub Continuous Integration for instance), I need a refresh token for an account with Spotify Premium to access the different endpoints the Spotify Web API exposes. The refresh token doesn't expire as often as an access token, so it's good enough for the tests.
The main tekore developer, Felix Hildén, currently uses his own personal account for this, which does work, but is far from ideal because the tests have to be written so that they don't modify his profile, and has to be secret so that noone else has access to it.
But for rspotify none of the devs (including myself) want to share their refresh token to run these tests for different reasons, specially because it gives access to the full account and we consider that too risky as open source collaborators.
We were wondering if it'd be possible to have Spotify offer "development accounts" for such testing purposes. The accounts themselves wouldn't even need to work to listen to music, only for the Spotify Web API endpoints, so the cost for this proposal would be none.
This is beneficial for Spotify because this way the Web API libraries could write considerably improved tests, and with it, Spotify would have a more stable and robust ecosystem. Not only would that increase the quality of the apps, but also Spotify's usage to some extent.