Public playlist, private surprise

Spotify let people view the playlist publicly, but its tracks endpoint still required genuine user authentication. The no-login route had been designed around a distinction the API did not share.

Symptom

Fullhouse’s simplest promise—paste a public Spotify playlist and make a bingo card without logging in—ended at an authentication error.

Wrong assumption

“Public in Spotify” sounded equivalent to “readable with an application token.” It was a reasonable product assumption and an inaccurate API contract.

Actual cause

Reading playlist tracks required real user authentication even when the playlist itself was publicly visible. A renamed playlist-tracks endpoint and reshaped response made stale examples especially unhelpful.

Fix

The no-login path now uses the host’s existing Spotify connection. Guests still avoid individual authentication; the authorization belongs to the person running the room.

Prevention

Probe third-party capabilities with the real API before designing a whole interaction around them. “Public resource” and “anonymous API access” are separate claims.

Lesson

Authentication is part of the product flow, not plumbing beneath it. The eventual host model was better than asking every bingo player to log in anyway.