Skip to main content
Livry has two API surfaces with different authentication models. Using the wrong one is the most common early integration mistake.

​
Management API — OAuth 2.0 access tokens

The Management API is for administering your Livry resources: creating Organizations, updating tokens, managing Applications. It is authenticated with an OAuth 2.0 access token issued by Livry’s identity provider. Request a token for the Livry API audience:
Then send it as a bearer token:
The Management API is not the API your application calls on every page load. It is an administrative interface — call it from your backend or your build pipeline, never from a browser.

​
Serving API — signed URLs

The Serving API is what your application calls at runtime to fetch a theme. It does not use bearer tokens. Instead, each Application holds a signing key. You compute a hash over the request using that key, and include it in the URL. Livry validates the signature before serving. This exists because theme fetches happen from the browser, at high volume, through a CDN. A bearer token would either have to be exposed to the client or force every request through your own backend; a signed URL can be safely constructed ahead of time and cached.
The signing key is a secret. Compute signatures on your server or at build time — never ship the key to the browser.
See Signed URLs for how to construct one.