Skip to main content
The Serving API is the hot path. It answers one question — what does this Organization’s theme resolve to — and it answers it fast, from a CDN, on every page load of your application.

​
Shape of the integration

  1. Your backend or build step constructs a signed URL for an Organization, using the signing key held by an Application.
  2. Your frontend fetches that URL.
  3. Livry returns the default theme with the Organization’s overrides already applied.
  4. Your application maps the returned tokens onto whatever your components consume — CSS custom properties, a theme provider, or your own runtime.

​
Why signed URLs rather than tokens

Theme fetches happen in the browser, at volume, and should be cacheable at the edge. A bearer token would either have to be exposed client-side or force every request through your own backend, adding a hop to something that should be a CDN hit. A signed URL can be computed server-side ahead of time, handed to the browser safely, and cached like any other static asset.
The signing key never belongs in client-side code. Compute signatures on your server or at build time.

Signed URLs

How to construct a signed URL.