Spotify API

Go to developer.spotify.com/dashboard and log in with your Spotify account. Click 'Create app.' Enter a name (e.g., 'My Bubble App'), a description, and a redirect URI. For the client credentials flow used in this tutorial, the redirect URI is not used — you can enter your Bubble app URL as a placeholder (e.g., `https://yourapp.bubbleapps.io`). Under 'APIs used,' select 'Web API.' Click Save. On your new app's dashboard page, click 'Settings.' You will see your Client ID immediately. Click 'View client secret' to reveal and copy the Client Secret. Keep both values handy — they go into your Bubble Backend Workflow as Private parameters. Note: the Spotify Developer agreement prohibits certain commercial uses. Review the Spotify Developer Terms of Service at developer.spotify.com/terms before launching a public-facing app, particularly around displaying streaming content or making Spotify data the primary feature of a competing music service.

First, create a Bubble data type to store the shared Spotify access token. Go to Data tab → Data types → click '+ Add a new type,' name it 'Settings.' Add a field: `spotify_access_token` (text) and `spotify_token_expiry` (date). You will use a single Settings record shared across the app (not per-user). Now create the token-acquisition Backend Workflow. Go to Settings → API tab → enable 'This app exposes a Workflow API.' Open the Backend Workflows editor and click 'New API Workflow,' name it 'Refresh Spotify Token.' Note: Backend Workflows require a Bubble paid plan. Inside the workflow, add an API call step using the API Connector (you will configure the API Connector in the next step, but you can pre-set the step). The workflow will POST to `https://accounts.spotify.com/api/token` with: Content-Type header `application/x-www-form-urlencoded`, body fields `grant_type=client_credentials`, `client_id=[your Client ID]` (Private), `client_secret=[your Client Secret]` (Private). After the API call returns, add a 'Create or make changes to a Thing' step: if a Settings record exists, update it; otherwise create one. Set `spotify_access_token` to the `access_token` from the response, and `spotify_token_expiry` to Current date/time + 3600 seconds (use Bubble's `:plus seconds` expression).

1{
2  "endpoint": "POST https://accounts.spotify.com/api/token",
3  "headers": [
4    { "key": "Content-Type", "value": "application/x-www-form-urlencoded" }
5  ],
6  "body": {
7    "grant_type": "client_credentials",
8    "client_id": "<private: your_spotify_client_id>",
9    "client_secret": "<private: your_spotify_client_secret>"
10  },
11  "response_fields": [
12    "access_token",
13    "token_type",
14    "expires_in"
15  ]
16}

Spotify access tokens expire after exactly 3,600 seconds (1 hour). Without automatic refresh, your Bubble app will silently stop returning Spotify data after the first hour — no error message, just empty repeating groups. The cleanest solution is a Scheduled API Workflow that runs every 55 minutes. In the Backend Workflows editor, look at the top-right area for 'Recurring events' or find the scheduling option for your 'Refresh Spotify Token' workflow. In Bubble, you can schedule an API Workflow to recur by using the 'Schedule API Workflow' step at the end of the workflow itself — this creates a self-scheduling pattern: after refreshing the token, the workflow schedules itself to run again in 55 minutes. Add a 'Schedule API Workflow' step at the bottom of 'Refresh Spotify Token,' set the workflow to 'Refresh Spotify Token,' and set the scheduled date to 'Current date/time + 55 minutes.' Also trigger the 'Refresh Spotify Token' Backend Workflow on your app's index page load (as an on-page-load workflow step) so a fresh token is always available when the first user visits. Scheduled API Workflows require a Bubble paid plan. On the free plan workaround: call the Backend Workflow on every page load and check expiry before making API calls — less efficient but functional.

Go to Plugins tab → add the API Connector (by Bubble) if not already installed. Click 'API Connector' → 'Add another API.' Name it 'Spotify.' Set the base URL to `https://api.spotify.com/v1`. Under 'Shared headers,' add: key `Authorization`, value `Bearer [Settings's First Item's spotify_access_token]` — this dynamic expression reads the stored token from App Data. Check the 'Private' checkbox. Bubble will substitute the dynamic value server-side, keeping the token out of browser requests. Now add individual calls. Click 'Add a call,' name it 'Search Tracks.' Method: GET. Path: `/search`. Add URL parameters: `q` (dynamic, the search query), `type` (value `track`), `limit` (value `20`), `market` (value `US`, or make dynamic for multi-market apps). Set 'Use as' to 'Data.' Click 'Initialize call' — enter a real search term in the `q` field (e.g., `Beatles`) and click Initialize. Bubble sends a live request and auto-detects the response structure: `tracks.items[]`, with fields including `tracks items name`, `tracks items artists 0 name`, `tracks items album images 0 url`, `tracks items preview_url`, `tracks items id`, `tracks items duration_ms`. Expand the `tracks` object and mark `items` as your list type.

1{
2  "api_name": "Spotify",
3  "base_url": "https://api.spotify.com/v1",
4  "shared_headers": [
5    {
6      "key": "Authorization",
7      "value": "Bearer <dynamic: Settings's First Item's spotify_access_token>",
8      "private": true
9    }
10  ],
11  "calls": [
12    {
13      "name": "Search Tracks",
14      "method": "GET",
15      "path": "/search",
16      "parameters": [
17        { "key": "q",      "value": "<dynamic>" },
18        { "key": "type",   "value": "track" },
19        { "key": "limit",  "value": "20" },
20        { "key": "market", "value": "US" }
21      ],
22      "use_as": "Data"
23    },
24    {
25      "name": "Get Audio Features",
26      "method": "GET",
27      "path": "/audio-features",
28      "parameters": [
29        { "key": "ids", "value": "<dynamic: comma-separated track IDs>" }
30      ],
31      "use_as": "Data"
32    }
33  ]
34}

Add a Search Input element and a Button to your Bubble page. Add a Repeating Group below — set its data type to 'Spotify Search Tracks' and its data source to 'Search Tracks from Spotify — tracks items' (the items list from your initialized call). Wire the q parameter to the Search Input's value. Add a workflow to the Button: run the 'Search Tracks' API call with the current input value and refresh the repeating group. Inside each repeating group cell, add: an Image element (source: `Current cell's Spotify Search Tracks tracks items — album images 0 url` — this is the first album art thumbnail), a Text element for track name (`tracks items — name`), a Text element for artist name (`tracks items — artists 0 name`). For the preview player: `preview_url` is the direct URL of a 30-second MP3 preview. Note that approximately 30% of Spotify tracks have a null `preview_url` — these have no free preview. Conditionally show an Audio element (add via the audio plugin or HTML element) only when `preview_url` is not empty. Use a Bubble Custom State to hold the selected track ID when a user clicks a row, then trigger the Get Audio Features call to show danceability, energy, and other attributes in a detail panel.

Go to Data tab → Privacy. Click on the 'Settings' data type you created for storing the Spotify token. By default, Bubble makes all records searchable by anyone — you need to restrict this. Add a privacy rule: 'When: Current User is logged in AND Current User's role is admin' (adjust for your app's access model) to allow reading and modifying the Settings record. Without a privacy rule, any visitor to your app could query the Settings table through Bubble's API and potentially read the access_token field. Since the token is used server-side in Private headers, exposure through Bubble's data API is the real risk. Also add a 'Check expiry' step to your main search workflow: before calling Search Tracks, check if Settings's First Item's spotify_token_expiry is less than Current date/time. If so, call the Refresh Spotify Token Backend Workflow as a first step. This ensures fresh tokens even if the scheduled refresh missed a cycle. Finally, test the full flow: run the app, search for a track, verify results load, wait (or manually set the expiry to a past date) to test token refresh, and verify results continue to load after refresh.