Spotify integration returns stale data on Vercel production but works locally

Other Questions Spotify
1

I’m using a music tracking library to display my current Spotify song. Everything works perfectly when I test it on my local machine, but after deploying to Vercel, the data gets frozen.

// api/current-track.js

import { MusicTracker, StreamingService } from '@bolajiolajide/now-playing';

export async function GET() {
  const tracker = new MusicTracker(StreamingService.SPOTIFY, {
    useCache: false,
    cacheDuration: 30000,
    streamerArgs: {
      clientId: process.env.SPOTIFY_APP_ID || 'DEFAULT_ID',
      clientSecret: process.env.SPOTIFY_APP_SECRET || 'DEFAULT_SECRET', 
      refreshToken: process.env.SPOTIFY_REFRESH_KEY || 'DEFAULT_TOKEN',
    },
  });

  try {
    const result = await tracker.fetchCurrentlyPlayingOrLastPlayed();
    return Response.json({ result });
  } catch (err) {
    return Response.json({ err });
  }
}

Locally when I switch songs, the API updates immediately. On Vercel production, it shows whatever song was playing during deployment and never updates. The environment variables are identical. The API keeps returning 304 status codes. Has anyone faced this caching issue before?

2

Vercel’s automatic caching is overriding your config. The useCache setting only handles internal caching - it won’t stop Vercel’s infrastructure from caching your stuff. Had the same problem with music apps I deployed. Vercel assumes your API route can be cached unless you tell it otherwise. Add this to force dynamic behavior:

export const dynamic = 'force-dynamic';
export const revalidate = 0;

Also check if you’re using App Router - caching works totally different between Pages and App Router. Your function might be getting cached at build time instead of running on each request. Those 304 responses mean this is happening before your code even runs. It’s CDN-level caching, not your application logic.

3

Had the same issue with my Next.js app on Vercel - API responses just wouldn’t update. Turned out to be Vercel’s edge caching mixed with serverless function handling. Even with useCache set to false, Vercel was still caching responses since there’s no explicit cache directive. I fixed it by adding timestamps to force cache busting, but the real problem was my Vercel function config. The serverless functions themselves get cached if they’re not set up as dynamic routes properly. Double-check your API route directory structure and make sure Vercel sees it as a dynamic endpoint. Also worth temporarily logging your environment variables to confirm they’re actually loading in production.

4

It seems that the issue you are experiencing is indeed related to caching on Vercel’s side. While you’ve set the no-cache option in your library, Vercel can still cache responses at their CDN level. To work around this, you should add cache control headers directly into your API’s response. For example:

const response = Response.json({ result });
response.headers.set('Cache-Control', 'no-store, no-cache, must-revalidate');
response.headers.set('Pragma', 'no-cache');
response.headers.set('Expires', '0');
return response;

Alternatively, you could configure the caching behavior in your vercel.json file to ensure that your API routes do not cache responses. The 304 status codes you’re encountering are indications of cached responses rather than issues within your Spotify integration.

5

Classic Vercel caching nightmare. I’ve hit this exact issue - works perfectly locally, then production turns into a frozen wasteland.

You’re fighting multiple cache layers: Spotify’s API, Vercel’s CDN, serverless function caching, and browser caching. They’re all working against you.

I fixed this by moving my Spotify integration to Latenode. Created a workflow that polls Spotify every 30 seconds and stores current track data. My frontend just hits a webhook endpoint that always returns fresh data.

Latenode handles OAuth refresh tokens, caching logic, and API rate limiting automatically. No more 304 responses or stale data. The workflow runs independently of your deployment, so song changes get picked up regardless of Vercel’s caching.

You can also add listening history or trigger actions when songs change. Way more reliable than wrestling with serverless functions for real-time data.

6

check your vercel.json config - you might have edge-level caching that’s ignoring your no-cache headers. also, spotify tokens can expire weirdly in serverless environments. try adding a random query param to break those cache cycles.