Catalog data is the exception — it needs no user token, even on V2:
- Movie, show and anime summaries by Simkl ID —
/movies,/tv,/anime - Episode lists —
/tv/episodesand/anime/episodes - The Trending and Calendar data files on
data.simkl.in
client_id, app-name and app-version, plus a User-Agent header — see Headers and required parameters. The exception is about the Authorization header only.Everything else requires a user token, including search, /redirect, and every sync, scrobble, ratings, custom-lists and user-settings endpoint.Which flow do I need?
OAuth flow
For web apps, mobile apps, SPAs, desktop binaries and browser extensions — anything that can open a browser. PKCE is mandatory for all of them.
Device / PIN flow
For TVs, consoles, watches, CLIs and media-server plugins — anything without a usable browser or keyboard. Show an 8-character code, the user types it on their phone.
client_secret. If you have not registered the app yet, Set up authentication walks the decisions in order — client type, secret, flow, scope — and is the page to read first.
You need a new client_id
Your existing V1 app keeps working while you migrate, so you can run both side by side: new sign-ins through the V2 app, existing users still served by the V1 one until they move. That is the recommended way to do it — see Migrating from V1 to V2.
How many client IDs do I need?
One per app type you actually use — not one per platform. A client type is fixed at registration, so a single registration cannot cover two of them.Everything through your backend
One client ID. Your backend signs users in, stores tokens and makes every API call. A mobile or TV interface that talks only to your backend does not need its own registration — it never touches Simkl directly.
Different types in one product
Two or three client IDs. Parts of your product sign in differently — an app callback here, a PIN-style device flow there, a server callback somewhere else. Each type needs its own registration.
Example: a product with a mobile app, a TV app, and a backend
Example: a product with a mobile app, a TV app, and a backend
Three parts, three different sign-in mechanics, so three registrations:
Start with the type you need now and add the others when you need them — there is no benefit to registering all three up front.
The three-registration example above fits inside the smallest allowance. Unverified apps are capped at 3 on Free, 5 on PRO and 10 on VIP — counted separately for AUTH V1 and AUTH V2, so the V1 apps you are migrating from never consume a V2 slot.Verified apps do not count at all, and verification is free on every plan. See Set up authentication.
What you get back
Every successful exchange returns the same shape, whichever flow produced it:
Both tokens are 43 characters and carry a recognisable prefix —
simkl_at_ for access, simkl_rt_ for refresh. Size your storage columns accordingly, and treat both as secrets.
Token lifetimes at a glance
Full detail, including the two refresh behaviours that surprise people, is on Tokens and refresh.
What the user sees
Your grant is not invisible to the person who approved it. Connected Apps shows every user, for every app they have connected:
Two consequences worth designing for. Asking for
media:write when you only read is visible, and sits next to apps that asked for less. And when a user says your app stopped syncing, that page settles it faster than any log you have: the allowance is theirs and shared across every app they run, so the cause is frequently another integration entirely — which you cannot see and they can.
Discovery — let your library configure itself
Simkl publishes a small JSON file listing its own endpoints and capabilities — the standard RFC 8414 “discovery document”, at/.well-known/oauth-authorization-server. It describes V2.
Most OAuth libraries know how to read it, which means you do not have to configure the authorize URL, the token URL and the supported auth methods yourself. Give the library one setting instead — https://simkl.com — and it fetches the rest. Libraries usually call that setting the issuer:
If your library looks for
/.well-known/openid-configuration, point it at OAuth 2.0 instead. Simkl is an OAuth 2.0 server, not an OpenID Connect provider, so the OIDC path returns 404 and the document you want lives at /.well-known/oauth-authorization-server. Libraries that try both in turn — Spring Security, for one — fall through on their own. Libraries that try only the one you selected need a flag: { algorithm: "oauth2" } in openid-client, for example. A 404 during setup usually means the library is looking at the OIDC path and has no fallback.https://simkl.com/oauth2/authorize and https://api.simkl.com/oauth2/token directly, as listed above. Discovery saves you typing, not capability.
See also
OAuth flow
The full walkthrough with PKCE, including the failures that are hardest to diagnose.
Device / PIN flow
RFC 8628, end to end — polling rules, expiry, and what the user sees.
Scopes
media:read and media:write, and why omitting scope gives you read-only.PKCE in V2
S256 only. How to generate the verifier and challenge correctly.
Client libraries
Per-library configuration, and the three defaults that need changing.
Migrating from V1
What actually changes, and what doesn’t.
AUTH V1
The original flow. Being retired around April 2027.
Errors
The OAuth 2.0 error vocabulary, and the envelope that differs.