Those are the real constraints, and later sections cover them. Read the table as an ownership map: the only paid item is the one a person holds, not the one a developer registers. It shows where a cost could sit. | Item | Cost | Who pays | Source page | |---|---|---|---| | API access | No charge stated | Nobody | Spotify for Developers, Web API documentation | | Dashboard app | No charge stated | Nobody | Spotify for Developers dashboard | | Dev mode | No charge stated; restricted to a limited set of users | Nobody | Spotify for Developers, quota modes documentation | | Extended quota | No fee stated; granted on Spotify's review | Nobody, but the app owner supplies the application | Spotify for Developers, quota modes documentation | | Premium account | Consumer subscription | The account holder | Spotify's Premium plans page | _Prices and plan limits checked against [community.spotify.com](https://community.spotify.com/forum/en/categories/spotify-for-developers) on October 22, 2026._ When a free-tier listener authorises your app, Spotify will still refuse some playback-control calls, because those require Premium. When teams route these calls through an automation tool such as [Activepieces](https://www.activepieces.com), they still inherit the same limits, because the connection belongs to whoever authorised it. Pick the interface before you request permissions, because each one needs its own token and scopes. The Web API reads and changes data over HTTP. The Web Playback SDK, by contrast, plays audio in a browser, and the mobile SDKs control the Spotify app on a device. ## Getting access and credentials step by step Once five actions in the developer dashboard are done, setup is finished, and the Premium account you perform them with becomes the owner of the app and its credentials. Choose that account as deliberately as you chose the interface. Follow the order below, because each step creates something the next one depends on. The sequence runs from login to the user allowlist. 1. Log in to developer.spotify.com with a Premium account. 2. Create an app. 3. Add redirect URIs. 4. Copy the client ID and client secret. 5. Allowlist up to five users, which means access is limited to five accounts.  Once these are done, you hold working credentials, and the remaining question is how to handle each one. ### Spotify API client ID, secret and redirect URIs Your client ID is safe to appear in a browser, because it only identifies your app. The client secret authenticates it, so keep it on the server and out of the repository.  If the secret leaks, whoever holds it can request tokens as your app, and the dashboard owner is the person who must rotate it. Register the exact string your code uses for each redirect URI, the address Spotify may send a user back to after consent. A mismatch fails the authorization request, and that failure is a safeguard against token interception. ### Development mode versus extended access New apps start in Development Mode. According to a [Spotify Community](https://community.spotify.com/forum/en/categories/spotify-for-developers) post citing the official documentation, that mode allows up to **five allowlisted Spotify users**. Spotify refuses anyone outside the list at authorization, so a launch to the public won't work from this mode.  To get past that limit, you apply to Spotify for extended access. Decide before building who your real users are. If they exceed the allowlist, plan the application as a project task, not a last-minute fix. ## Choosing an authorization flow and scopes Use authorization code with PKCE for anything that touches a user's account, and client credentials only when the app needs catalog data. Either way, name the person or team who owns the app registration and its credentials before Spotify issues the first token. Only the two code flows combine user data with a refresh token; the table shows which flows reach user data and which hold a secret. | Flow | User data reachable | Secret stored | Best-fit use case | Refresh token issued | |---|---|---|---|---| | Authorization code | Yes | Client secret, server-side | Web apps with a backend | Yes | | Code with PKCE | Yes | None; a per-request code verifier | Mobile, single-page and desktop apps | Yes | | Client credentials | No | Client secret, server-side | Catalog lookups, no user | No | | Implicit grant (deprecated) | Yes | None | Nothing new | No | Treat the implicit grant as a migration task, not an option, because Spotify has deprecated it. When a server can keep the client secret, pick authorization code. When it can't, pick PKCE, because there's no secret to leak. Both return a refresh token, so the user consents once. Because client credentials authenticates the app, not a person, it can't read a playlist library or listening history, and it issues no refresh token, so the app simply requests a new token on expiry. ### Scopes and token lifetime 17 scopes are defined by Spotify, and [Spotify for Developers](https://developer.spotify.com/documentation/web-api/concepts/scopes) groups them by what they let an app do. Playlists has 4 scopes, so a playlist tool must separate read from write, public from private. Listening history, users and Connect have 3 each, according to Spotify for Developers, so a recommendation feature needs a different consent screen than a remote-control one. Playback and library have 2 each, per Spotify for Developers, so a player that only saves tracks shouldn't request playback control. Request the smallest set, because each added scope widens what a leaked token exposes. Access tokens last one hour, so build refresh handling in from the start. ## Available and restricted Spotify API endpoints by group Although most endpoint groups remain open to new apps, the November 2024 deprecations and the February 2026 search change restrict the rest, and the token you refresh differs by group. The table below shows what each group returns, which token it needs, and what changed, as of 22 October 2026. | Group | Returns | Auth needed | Status and date changed | |---|---|---|---| | Search | Matching tracks, albums, artists, playlists | App token | Lower result limits, Feb 2026 | | Albums | Album metadata and track lists | App token | No change noted | | Artists | Artist metadata, albums, top tracks | App token | Related artists removed for new apps, Nov 2024 | | Tracks | Track metadata | App token | Audio features and analysis removed for new apps, Nov 2024 | | Playlists | Playlist contents and edits | User token, playlist scopes | Spotify-owned playlists restricted, Nov 2024 | | Player | Playback state, device control | User token, playback scopes | No change noted | | Library | Saved tracks, albums, followed items | User token, library scopes | No change noted | | User profile | Account details | User token, profile scopes | No change noted | | Restricted items | Recommendations, featured and category playlists, preview URLs | Closed to new apps | Nov 2024 | Read the auth column first: it tells you whose credential each call runs under, and therefore who owns the connection. Because albums, artists and tracks need only an app token, they carry no user consent. Search uses the same token, but since February 2026 it returns fewer results per request, so pagination replaces a single wide query. Anything in the library, playlist and player groups acts on one person's account, so each needs a user token with the matching scope, such as `user-library-read`, `playlist-modify-private` or `user-modify-playback-state`. Request only what you use. Player control also depends on the account's subscription. Since the November 2024 changelog, recommendations, related artists, audio features, audio analysis, featured and category playlists, and preview URLs have been **closed to new apps**. **An app built on them will fail at its first call, so check the changelog before you design around any of them.** ## A minimal working Spotify API request To make a minimal working request you need two calls: post your app's client ID and secret to the accounts service for a token, then send that token as a Bearer header to a catalog endpoint.  Client credentials involves no user, so the app registration owner is the only identity involved. Send a form-encoded POST to the accounts host, not the API host. Keep the secret in an environment variable, because whoever holds it can act as your app. ```bash curl -X POST https://accounts.spotify.com/api/token \ -H "Content-Type: application/x-www-form-urlencoded" \ -d grant_type=client_credentials \ -d client_id=$SPOTIFY_CLIENT_ID \ -d client_secret=$SPOTIFY_CLIENT_SECRET ``` In the response you get `access_token`, `token_type` (Bearer) and `expires_in`. This token has no user scopes, so it can read public catalog data and nothing tied to a listener's account. ### Calling a Spotify API catalog endpoint Pass the token in the `Authorization` header on the API host. ```bash curl "https://api.spotify.com/v1/search?q=miles%20davis&type=artist" \ -H "Authorization: Bearer $ACCESS_TOKEN" ``` Most often the failure is a malformed header: the word `Bearer` omitted, a missing space after it, or the client secret pasted where the token belongs. Any of these returns a 401, which reads like an expired token but isn't one. Check the header string before you suspect the app. In an automation tool's run log, a healthy call looks like an HTTP step that sent a POST with an Authorization header and got back a 200 with "OK". The same check applies to your own request.  In the search response, an `artists` object holds an `items` array of the matches. Each item includes `id`, `name`, `type` and `uri`. Store the `id`, since every later catalog call is keyed on it. If `items` is empty, the call worked and the query matched nothing, which is a different problem from a 401. ## Spotify API rate limits and how they behave Send too many calls and you get HTTP 429 and a `Retry-After` header, because Spotify measures call volume per app over a **rolling 30-second window**. A 429 means the token and the query were fine, but the app behind them sent too much. ### The rolling window and what is unpublished Because the window is rolling, there's no clock-minute boundary at which your count resets. Bursts are judged against the last 30 seconds, whatever happens to be inside them. Spotify doesn't publish a fixed request count for that window, so any number in a blog post or forum thread is an observation, not a guarantee. Don't hard-code one. Read `Retry-After`, wait that long, and retry, with the delay owned by a single queue rather than by each caller. Request size matters as much as request count. **Search now returns smaller pages** than it used to, as the chart shows: the old maximum was 50 and the old default 10, against a new default of 5 and a new maximum of 10. Anything above 10 returns HTTP 400, not a trimmed page. If your code asked for 50 results per call, it will now fail outright, and code relying on the default gets half the results per request. Either way, collecting the same results takes more calls inside the same window. ### Development mode versus extended quota With a lower quota and a limited set of authorised users, an app starts in development mode. Extended quota is a separate approval that Spotify grants to the app, not something you switch on. Spotify doesn't publish the numerical gap between the two, so the only way to find your ceiling is to log every 429 and its `Retry-After` value in production-like conditions. Name an owner for the app registration before launch. That person holds the quota request, and if they leave, nobody can answer Spotify's questions about it. ## Common Spotify API errors and fixes Whoever inherits that connection also inherits its error log, and six status codes account for most of what appears there; only some of them are worth retrying. The table shows each code's usual cause, the fix, and whether a retry helps. Treat the last column as policy: a client that retries a 403 only generates more failed calls. | Status | Usual cause | Fix | Retry? | |---|---|---|---| | 400 | Malformed request, bad parameter or body | Correct the request against the endpoint reference | No | | 401 | Expired access token | Exchange the refresh token for a new access token | Once, after refreshing | | 403 | Missing scope, or user isn't allowlisted in development mode | Re-authorize with the scope, or add the user in the dashboard | No | | 404 | Wrong ID, deleted item, or unavailable in the market | Verify the ID and market | No | | 429 | Rate limit exceeded | Wait as the response instructs | Yes, after the wait | | 5xx | Fault on Spotify's side | Back off and try again | Yes, a limited number of times | Only the 401, 429 and 5xx rows reward automation. The rest need a person to change something. When you see a 401, the access token has expired, so refresh it and repeat the call once. A 403 means the token is valid but not permitted: either the scope was never requested, or the user isn't allowlisted for an app in development mode. Both need a named owner who can edit the app settings. Wait exactly as long as the Retry-After header on a 429 says before the next call; guessing a shorter pause extends the block. Cache responses that rarely change, such as album and artist metadata, and use batch endpoints that accept several IDs per request, so you make fewer calls. A 5xx is Spotify's fault, not yours. Retry with exponential backoff and a hard cap on attempts, then log the failure and stop. An unbounded retry loop turns a short outage into a rate-limit problem. ## What Activepieces does about this Activepieces is an open-source automation tool, and its community edition is released under the MIT licence. That matters for the problems above because the constraints are ones you inherit rather than ones a tool removes. With a self-hosted copy, you can read how a connection stores a token and how a step handles a failed call, instead of guessing. Credentials live in a connection, and a connection belongs to a project, not to whoever happened to build the flow. For Spotify, that means the client ID, the secret and the consenting account sit in one place that you can name and audit. It is the "who owns the app registration" question made concrete. You still register the app in the Spotify dashboard yourself, and you still choose the scopes on the connection. Activepieces will not widen a development-mode allowlist or grant extended quota, and it cannot make a 403 permitted. For calls a prebuilt step doesn't cover, the HTTP integration lets you send the same requests shown earlier: a form-encoded POST to the accounts host, then a Bearer header on the API host.  Each run records what a step sent and received, so a 401 caused by a malformed header can be told apart from an expired token, and an empty `items` array from a failed call. Step-level retry settings suit the 429 and 5xx rows of the error table. Keep a hard cap on attempts, and set your own wait to match `Retry-After`. Leave the 400, 403 and 404 rows to a person, as the table says, these error codes require human attention. ## Frequently asked questions Is the Spotify API free to use? Yes, registering an app and calling the Web API carries no charge, so cost isn't what limits you. Access mode, scopes and rate limits are. The app registered in your developer dashboard is owned by the account that created it, so decide early whether that's a personal login or a team one. ### Can I use the Spotify API for a commercial app? Only within Spotify's developer terms, and in practice only after your app leaves development mode. Development mode is meant for building and testing. To serve the public, you apply for extended access and Spotify reviews the app against its policies. Before you build, check that your use case is permitted, because a product that depends on a use Spotify won't approve can't be fixed by writing better code. Request only the scopes the product needs, since the review looks at what you ask for. ### Does the Spotify API give me full songs to play? No, the Web API returns metadata and playback control, not audio files. You can read tracks, albums, playlists and a user's library, and you can tell an active Spotify player what to play. Playing audio inside your own app goes through Spotify's playback SDK, and that requires the listener to hold a Premium account. You can't download, store or re-serve the audio, so design the product around controlling playback rather than delivering it. ### How many users can use my app in development mode? Only a small, hand-picked group. In development mode, each user must be added to the app's allowlist in the dashboard before their authorization will work. Anyone outside it is refused at login, which looks like a bug until you know the cause. Treat the allowlist as an access register: name who maintains it, and record who's been added and why. If you expect real users, plan the move to extended access before launch. ## Related reading - [Cursor AI Pricing 2026: Free Plan Limits and Features](https://www.activepieces.com/blog/cursor-ai-pricing-2026-free-plan-limits-and-features) - [Supabase Pricing: Free Tier Limits, Pro Costs & Egress](https://www.activepieces.com/blog/supabase-pricing-free-tier-limits-pro-costs-egress) - [How to Give Contractors Access to One Automation](https://www.activepieces.com/blog/what-to-check-in-the-run-log) ## References - [Spotify for Developers](https://developer.spotify.com/documentation/web-api/concepts/scopes)Before asking about cost, ask who owns the registered app and which user authorised it, because every token traces back to those two.