Skip to main content
Livry is built around four objects. Understanding how they nest — and which boundaries are deliberately impermeable — is the fastest way to model your own setup correctly the first time.

Team

A Team is the customer account. It owns billing, and it is the unit across which resources are shared between people. If you work with several organisations or client accounts, you can belong to more than one Team. Teams are fully isolated from each other.

Tenant

A Tenant is an environment — typically one for sandbox and one for live. Tenants exist so you can develop and test theme changes without touching what your production traffic is serving. A Team can hold multiple Tenants. Everything below this level belongs to exactly one Tenant.

Organization

An Organization is a brand. It holds a set of overrides applied on top of your default theme, so each brand you serve only has to express what makes it different rather than restating an entire theme.
Organizations do not move between environments. An Organization created in your sandbox Tenant stays there — there is no built-in promotion from sandbox to live. If you need environment promotion, drive it through your own tooling against the Management API.
This is a deliberate design decision. Environments stay genuinely independent, so a sandbox experiment can never partially leak into live through a half-completed promotion.

Application

An Application is the holder of a signing key. Themes are served over signed URLs, and the Application is what the signature is computed against — it’s how Livry knows a request for a theme is legitimately yours. Create an Application for each consuming surface that needs to fetch themes independently.

How they nest

Tokens

Themes are expressed as tokens stored as JSON. The token document is schema-less by design: Livry does not impose a fixed vocabulary of token names, so you can model whatever your design system actually uses rather than mapping it onto someone else’s taxonomy. The trade-off is that Livry cannot validate token names for you. Consistency across Organizations is your responsibility, and it’s worth establishing your token vocabulary before you onboard your second brand.