Skip to main content
The serving edge is the hot path. It answers one question — what does this brand’s theme look like — and it answers it from a static file.

​
Nothing is computed at request time

A publish materialises every (Theme, Variant, version) combination into rendered files ahead of time. A request is a blob read behind a cache: no resolution, no database, no merge.
That is why the serving path can sit on the render path, and it is why nothing is served until you publish. A Theme with a draft and no published version answers 404.

​
The URL

Ids, not slugs. A slug can be renamed, and a serving URL is embedded in your app and covered by a signature. A slug in the path would make every rename break every integration. Five segments always. A Theme on its own carries - rather than omitting the segment, so every URL has the same shape.
These URLs are a contract. Once your app is deployed against them they are embedded in your builds and cached at every layer between you and your users. Livry treats a change to this grammar as a breaking change, not a refactor.

​
Which files exist

A Theme serves only the files its integrations need — not all five. That is decided by the framework and library pairs on the Theme’s Integration tab. If you ask for a file the Theme does not serve, you get 404. The portal and the API both list the URLs that actually exist, so you never have to guess. See What gets served.
A Theme with no integrations serves nothing. Themes created before integrations existed are in that state; adding a pair on the Integration tab and republishing fixes it.

​
Two addresses, and you want both

latest

Moves when you publish. Cached for your Environment’s lifetime — 60 seconds by default.Good for sandbox, and for production if you want publishes to reach users without a deploy.

Pinned — /7/

Version 7, frozen. Its bytes never change, so it is cached for a year.Good for production if you want a theme change to ship like any other change.
See Caching for the trade-off in full.

​
Authentication

There is no bearer token on the serving edge. A Theme is either: A new Theme is public, because the fastest integration is a plain fetch. Signing is opt-in per Theme — see Signed URLs. Independently of the mode, a Theme can restrict which origins and which IP ranges may fetch it. See Access control.
Never send a Public API bearer token to the serving edge. They are different surfaces with different credentials, and the API token is an administrative one that does not belong in a browser.

​
The zero-code integration

That is a complete integration. Everything else — Tailwind, Chakra, a build-time pipeline — is a way of making your existing code reference those custom properties. See Integration guides.

Signed URLs

The HMAC scheme, in full, with a worked example.