A keychain that plays a song: building the Spotify Code mode

This is a keychain that plays a song. Scan the code on it with the Spotify app and the track opens — a physical object that points at a piece of music, a gift that says “this one is ours” without a single word printed on it.

This is a disip build. The shared pipeline — design in the browser, generate a .3mf on add-to-cart, store it, attach it to the WooCommerce order, fixed €4,50 enforced server-side — is the same across all our keychains, and we wrote it up in how we built the configurator. This post is only about the part that is unique to the Spotify Code mode: getting a real, scannable code onto a printed plate.

You cannot generate a Spotify Code offline

The first thing we learned: a Spotify Code is not something you can compute from a track ID. The bar pattern comes from a reference assigned on Spotify’s side — there is no public algorithm to draw it yourself. So the only correct way to get the artwork is to ask for the official one.

Spotify Codes are an intended sharing feature, and the official scannable images live on an open CDN. We build the URL from the track’s URI and fetch the SVG directly in the browser:

• Normalise the input. Paste a share link, a spotify: URI, or a scannables URL — they all collapse to a single spotify:type:id. The URL host is fixed in code, and two regexes reject any URI carrying a slash, query, fragment, space, or stray character — so the input can’t be steered at another address.
• Fetch it live. The CDN at scannables.scdn.co serves the SVG CORS-open, so the browser reads it directly — no server proxy needed. Nothing from Spotify is bundled in our code; the artwork is fetched fresh every time and never stored in the repo.
• Keep the door open anyway. The fetch is pluggable. The widget exposes a fetchImpl and a urlForUri hook, so the WooCommerce plugin can later route through its own cache or proxy without touching the engine. Today it doesn’t have to.

One consequence worth noting: the design is never serialised into the saved parameters. We store only the URI and re-fetch the code from it, so the plate is always built from a live, official scannable.

From an SVG to a printable plate

An SVG is a picture, not a 3D object. To print it we have to turn its shapes into closed contours and extrude them. A Spotify Code is two kinds of shape, and we handle each on its own terms.

The bars are rounded rectangles in the SVG. We read every <rect>, drop the full-cover background, and turn each remaining bar into a stadium contour — a rectangle with semicircular ends, matching the rounded caps of the original.

The logo is a single curved <path> nested inside a translated group. We flatten that path — M, L, H, V, C, S, Q, T, plus a proper elliptical-arc fallback in case the artwork ever changes — into polygons, then union the subpaths so the wave cut-outs come through as actual holes, not overlapping fills. SVG runs y-down and the printer thinks y-up, so everything is flipped and scaled into millimetres before it reaches the shared contour core all our modes use.

A scannable code is only a code if a phone can still read it after it’s been printed.

The scannability problem

The code is wide and short. That shape fights you on a keychain, where the instinct is to make everything small. But the bars carry the data, and the narrowest one is the weakest link: shrink the card and that bar can drop below what a 3D printer can resolve and a camera can separate.

So the build measures it. As it lays out the plate, it computes the printed width of the thinnest bar and warns you if it falls under 0.8 mm — the point where the bars start to blur into each other. The default card is 70 mm wide with a small uniform margin, which keeps that thinnest bar comfortably above the line while staying pocket-sized.

Contrast does the rest, and that part we leave to a sensible default rather than a check. A camera reads a code by the difference between the bars and the plate, so the design opens on the high-contrast pairing everyone recognises: a green card with a black code. You can recolour both — but flatten that contrast and you get a pretty plate that won’t scan. A Spotify Code keychain that can’t be scanned serves no purpose, so the default is built to be read.

A deliberate choice: point it at a song

You can encode anything Spotify can share. We frame the product around a personal track rather than an editorial playlist on purpose. A song is a gift — the first dance, the road-trip track, the one that was playing. That is what a keychain in a pocket should mean: a personal pick, not a promotion.

One honest note on what this is. Spotify Codes are an intended consumer sharing feature, and that is all we use them for: you scan the printed code with the Spotify app, and your track opens. Compatibility, not partnership. We think that is the right way to build on top of someone else’s platform — build on the public feature, and claim no more than that.

disip is not affiliated with, endorsed by, or sponsored by Spotify. “Spotify” and the Spotify Code feature are trademarks of Spotify AB.