Skip to main content
Soundlink’s authorization server lets your application act on behalf of a Soundlink organization. A user grants consent once; your application records the organization id and uses it for ongoing access.
Issuer: https://api.getsoundlink.com · Access token lifetime: 3600 seconds · PKCE: required (S256) · Refresh tokens: not issued

​
Which grant do I need?

Authorization Code + PKCE

A user signs in and approves scopes. Use this to establish the connection and to read identity via userinfo.Produces a token that acts as the user.

Client Credentials

Your application authenticates as itself for an organization it already has a grant for. Use this for ongoing, unattended access.Produces a token that acts as your application.
You will need both. Only the consent flow creates a grant, and Client Credentials requires an existing grant — so a client configured with Client Credentials alone cannot bootstrap itself.
There are no refresh tokens. An Authorization Code token cannot be renewed — when it expires after one hour, the user must consent again. A Client Credentials token can be re-requested at any time. Design your integration around the Client Credentials grant for anything long-running.

​
Discovery

Read endpoint locations from the metadata document rather than hardcoding them.
Response
The response is cacheable for 300 seconds (Cache-Control: public, max-age=300). The values in this document are authoritative — if they ever differ from the paths written here, follow the document.

​
Onboarding your client

Soundlink registers confidential clients for you. There is no self-service or dynamic client registration, and public clients are not supported. Provide the following when requesting a client:
​
string
required
Display name shown to users on the consent screen.
​
string[]
required
Every callback URL your application will use. Must be absolute HTTPS URLs. Matched exactly at authorize time — no wildcards, no path or query flexibility, no trailing-slash tolerance.
​
string[]
required
Request both authorization_code and client_credentials (see above).
​
string[]
required
The maximum set your client may ever request. Any scope sent to /authorize must be a subset of this.
​
string
Optional. Absolute URL, shown on the consent screen.
You will receive a client_id and a client_secret.
The client_secret is shown exactly once, at registration. Soundlink stores only a hash and cannot recover it. Store it in a secrets manager immediately; if it is lost, the client must be re-registered.
Because redirect URIs must be HTTPS, local development needs an HTTPS tunnel (ngrok, Cloudflare Tunnel, or similar). Register the tunnel URL as an additional redirect URI.

​
Reference application

A complete, runnable implementation of everything above:

soundlink-oauth-example

Next.js app covering the PKCE connect flow, server-side code exchange, userinfo, minted Client Credentials tokens, the campaign and metrics reads, and grant revocation — with every token held server-side and never sent to the browser.
Useful entry points:

​
Known limitations

No refresh tokens

Authorization Code tokens cannot be renewed. Use Client Credentials for anything ongoing.

No organization discovery

No endpoint lists the organizations that authorized your client. Persist organization_id at consent time.

No token introspection

No introspection endpoint and no JWKS. Token validity is knowable only by using it.

Confidential clients only

No dynamic client registration and no public-client support.

​
Next

Authorization Code + PKCE

Connect a user’s organization step by step, then read their identity via userinfo.

Client Credentials

Mint unattended tokens for an existing grant, and revoke a grant when done.

Scopes, endpoints & errors

Which scope unlocks which route, error codes, and a security checklist.