> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livry.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# What Livry Serves: The Five Rendered Files

> tokens.css, tokens.json, tokens.flat.json, tokens.dtcg.json and tokens.values.json — what each contains, and which of them your Theme actually builds.

A publish renders the resolved theme into up to five files. They are five views of the same thing —
pick the one your stack wants.

| File | Contains | Aliases |
| - | - | - |
| `tokens.css` | Custom properties on `:root` | Resolved |
| `tokens.json` | The DTCG document | Resolved |
| `tokens.flat.json` | Dotted path → resolved value | Resolved |
| `tokens.dtcg.json` | The DTCG document | **Left as written** |
| `tokens.values.json` | Dotted path → value as a **CSS string** | Resolved |

<Warning>
  **Your Theme does not serve all five.** It serves only what its integrations require, and asking
  for anything else returns `404`. The table further down maps integration to files; the portal's
  Integration tab and the API's `servingUrls` both list the URLs that actually exist.
</Warning>

## `tokens.css`

The zero-code integration. A `<link rel="stylesheet">` is a complete one.

```css theme={null}
/* Generated by Livry. Do not edit. */
:root {
  --color-brand-primary: #5B4DE4;
  --color-brand-hover: #5B4DE4;
  --space-md: 12px;
}
```

**Property names are the token path, hyphen-joined**, with an optional prefix:

```text theme={null}
color.brand.primary                 →  --color-brand-primary
color.brand.primary  (prefix acme)  →  --acme-color-brand-primary
```

The prefix is a Theme setting. If you generate CSS that references these properties, read it from the
Theme's `assetSettings.prefix` rather than assuming it is empty.

<Note>
  **It is a lossy projection, and it says so in the file.** CSS has no token types, no groups and no
  descriptions, and several DTCG values have no CSS spelling at all — a stroke style with a dash
  array, a colour in a space CSS cannot name.

  A token that cannot be written becomes a **comment naming its path**, rather than being dropped
  silently or guessed at. Diff the stylesheet against your tokens and you can see exactly what is
  missing and why.
</Note>

Characters that could end a declaration or open a block are refused rather than escaped, so a token
value cannot escape its declaration and inject CSS into your page.

## `tokens.json`

The full DTCG document, resolved: the tree, the groups, `$type`, `$description`, `$extensions`, and
every alias replaced by the value it pointed at.

Use it when you want the structure and the metadata — building a theme editor of your own, or driving
a token pipeline that cares about types.

## `tokens.dtcg.json`

The same document with **aliases left as written**.

```json theme={null}
{ "color": { "hover": { "$value": "{color.brand}" } } }
```

This is the one to feed a DTCG tool — Style Dictionary and friends resolve references themselves, and
handing them a pre-resolved document throws away the relationships they are built to use.

## `tokens.flat.json`

```json theme={null}
{
  "color.brand.primary": { "colorSpace": "srgb", "components": [0.357, 0.302, 0.894], "hex": "#5B4DE4" },
  "space.md": { "value": 12, "unit": "px" }
}
```

Dotted path to the **typed** value. Use it when you want to look a token up by path without walking a
tree, and you care about its structure.

## `tokens.values.json`

```json theme={null}
{
  "color.brand.primary": "#5B4DE4",
  "space.md": "12px"
}
```

Dotted path to the value **as a CSS string**.

This exists for libraries that derive shades or contrast from a colour in JavaScript. Those cannot
read a `var()` — they need a real value — so they get this file instead of `tokens.css`.

<Warning>
  **A theme built from this file does not rebrand by swapping a stylesheet.** The values are baked
  into your JavaScript at fetch time, so switching Variant means re-fetching and re-rendering. That
  is the cost of a library that computes on values, and it is why `tokens.css` is preferred wherever
  a library will accept `var()`.
</Warning>

## Which files your Theme builds

Decided by the **library** half of each integration pair:

| Library | Builds |
| - | - |
| Plain CSS, Tailwind CSS, Chakra UI, shadcn/ui, Angular Material, Skeleton | `tokens.css` |
| MUI, Vuetify, PrimeVue, PrimeNG | `tokens.values.json` |
| Build-time tokens (Style Dictionary) | `tokens.dtcg.json`, `tokens.json`, `tokens.flat.json` |

A Theme with several integrations builds the union. Adding an integration builds the extra files on
the next materialisation; removing one **deletes** the files nothing else needs, for every published
version.

<Note>
  MUI, Vuetify, PrimeVue and PrimeNG are placed on `tokens.values.json` **conservatively** — chosen
  because those libraries have historically computed on values, not verified against each library's
  current version. If yours accepts `var()` throughout, ask us to move it; it is a one-line change
  and costs you a smaller payload.
</Note>

## Content types

| File | `Content-Type` |
| - | - |
| `tokens.css` | `text/css; charset=utf-8` |
| everything else | `application/json; charset=utf-8` |

<Note>
  Plain `application/json`, not the `application/design-tokens+json` the DTCG spec suggests. That
  type is not IANA-registered, and `fetch().json()` and every CDN's compression rule key on the plain
  one.
</Note>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.