Client
Server
Reference / @open-music-sdk/user-token
@open-music-sdk/user-token
You probably don't want this package. Most apps install one integration and import everything from it: see Which package to install in the repository's README.
Everything around a listener's Music User Token except issuing it: asking Apple whether it works, taking it in from your page, and keeping it where core's forUser(userId) finds it. Only Apple's sign-in issues the token. This package starts once you hold the string. For your own account, the CLI's login gets one from the terminal.
Most apps install server, browser or react instead, which re-export what an app uses of this package. Use this one to build your own client.
Installation
pnpm add @open-music-sdk/user-token @open-music-sdk/core @open-music-sdk/developer-tokendeveloper-token is for the example's developer token. Keep them all on the same version. See One version for every package.
Documentation
- The documentation site: guides for each client and server, concepts, and the reference
- Reference for this package
- Keep a listener's token on your server: the intake route, its answers,
acceptUserTokenfor other frameworks, and choosing a store - Sign a listener in, which gets the token in your page
- The command-line tool, which gets one for your own account
- Deploy a Worker, for
KvUserTokenStoreon Workers KV - Developer tokens and Music User Tokens: where the token can go, and how to treat it
- Security model, for what the intake route and the stores do and don't protect
Example
On your server. sessionOf(req) and userId stand for your own session lookup:
ts
import { createClient } from "@open-music-sdk/core";
import { developerTokenMinter } from "@open-music-sdk/developer-token";
import { MemoryUserTokenStore, userTokenIntake } from "@open-music-sdk/user-token";
const store = new MemoryUserTokenStore();
const music = createClient({
developerToken: developerTokenMinter({ pem: process.env.APPLE_MUSIC_PRIVATE_KEY!, teamId: process.env.APPLE_MUSIC_TEAM_ID!, keyId: process.env.APPLE_MUSIC_KEY_ID! }),
userTokenStore: store,
});
// The route your page posts { "token": "..." } to. Apple checks the token, and only then does the store keep it.
export const POST = userTokenIntake(music, { store, userId: (req) => sessionOf(req) });
// In any later request, the listener's token is looked up in the store.
const playlists = await music.forUser(userId).request("v1/me/library/playlists");What's in it
A verb does the thing once. A userToken… noun is something to hand on, such as a handler for your router. The stores are classes, which you give createClient as userTokenStore.
| Export | What it does |
|---|---|
validateUserToken(client, token, options?) | Asks Apple whether the token works, and resolves to the listener's storefront |
acceptUserToken(client, store, userId, token, options?) | Checks the token with Apple, and only then stores it under userId |
userTokenIntake(client, options) | acceptUserToken behind a web-standard handler, (req: Request) => Promise<Response> |
MemoryUserTokenStore | A store in the process's memory, gone on restart |
KvUserTokenStore(kv, options?) | A store over Workers KV, or anything with KV's get, put and delete |
tValidateOptions, tIntakeOptions, tKvStoreOptions | The options each of those takes |
tUserTokenIntake, tKvNamespace | The handler's type, and the part of a KV namespace the store uses |
tUserTokenStore | core's interface for a store, for one of your own |