> ## 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 Is Not Built Yet

> An honest list of what exists in Livry today, what is partial, and what is still a plan — so you can judge whether it fits before you commit.

Livry is early. This page is the list we would want to read before committing an integration to a
date.

<Note>
  Everything on the rest of this site describes behaviour that exists. This page is the other half:
  what a reasonable person might assume is there, and is not.
</Note>

## What works today

* **The whole authoring path.** Sign up, create Environments, Themes and Variants, edit tokens,
  import from four formats, version and publish — all self-serve in the portal.
* **Serving.** Publishing materialises the rendered files, and the edge serves them public or signed,
  with origin and IP allowlists and real cache behaviour.
* **Access control.** Team roles and per-Environment grants are enforced, on the portal and the API
  alike.
* **The Public API.** Every read and write documented in the [API Reference](/api/introduction).

## Machine credentials are not issuable

<Warning>
  **The biggest gap for an automation-minded team.**

  Livry's model has a machine identity with its own Team role and Environment grants. Nothing
  provisions one, and the sign-in path does not resolve one — so the Public API is reachable today
  **only with a user-backed token**.

  In practice that means an API integration runs as a person, which is not something to put in a
  shared CI pipeline. If unattended automation is central to your plan, talk to us before you build
  around it.
</Warning>

## No in-app upgrade

There is no checkout flow and no customer-portal link. A plan change is made in the billing
provider's dashboard or set by Livry staff.

If you want to move from Free to Pro, [get in touch](mailto:support@livry.dev).

## Deletion is recorded, not executed

An Owner can request deletion of a Team or an Environment, and Livry staff can approve, decline or
withdraw the request.

<Warning>
  **Nothing actually deletes.** The execution step — cascading the records, pruning the stored files,
  tearing down the identity-provider organization, cancelling the subscription — is not built. An
  approved deletion is a recorded decision.

  If you need data genuinely removed, say so in the request and follow up with support.
</Warning>

Deleting a **Theme or a Variant** is different and does work immediately and irreversibly.

## Coming-soon screens in the portal

Two areas exist in the Environment settings and do nothing:

| | Status |
| - | - |
| **Custom serving domains** | Not built. Serving is on `cdn.livry.dev` only. |
| **Webhooks** | Not built. There is no event delivery of any kind. |

There is no way to be notified when a publish finishes — poll the pinned URL instead. See
[Caching](/serving/caching).

## Limits of the model, by design

These are not gaps and will not change:

| | |
| - | - |
| **No scope below an Environment role** | You cannot grant access to one Theme or one Variant. Build that yourself on the API. |
| **No promotion between Environments** | Nothing moves; script it. |
| **No mode (light/dark) concept** | Model it in your own CSS, or with two Themes. |
| **No reseller-facing editor** | Livry does not host one. |

## Smaller sharp edges

<AccordionGroup>
  <Accordion title="A Variant can be published only once per Theme version">
    Its version number *is* the Theme version its overrides answer. A second publish against the same
    Theme version answers `409`. Publish the Theme first.
  </Accordion>

  <Accordion title="A rename expressed as remove-and-add can lose an override">
    When a Theme publishes, Variants are migrated onto the new structure. A rename sent as `move` is
    tracked exactly; a remove-and-add pair has to be inferred, and the inference can lose an override
    when the rename also changed the value, or when two identically valued tokens are renamed
    together.
  </Accordion>

  <Accordion title="$extends and $ref are preserved but never applied">
    A DTCG document relying on either imports with tokens missing, and nothing warns you. Use
    aliases.
  </Accordion>

  <Accordion title="Themes created before integrations existed serve nothing">
    They have no framework/library pair, and a Theme serves only what its pairs need. Add one on the
    Integration tab and republish.
  </Accordion>

  <Accordion title="Plan enforcement counts, then creates">
    Two creates at the same instant can leave a Team one over its allowance.
  </Accordion>

  <Accordion title="The API takes etag as a query parameter, not If-Match">
    `If-Match` is the correct idiom and is where this will end up. Moving it is a breaking change to
    the API surface, so it will happen before the first customer depends on it.
  </Accordion>

  <Accordion title="No Location header on a 201">
    The created resource's `id` is in the body.
  </Accordion>

  <Accordion title="No resolved-theme endpoint on the API">
    Resolution is what the edge serves. An API endpoint that disagreed with the CDN would be two
    answers to one question — fetch the URL in `servingUrls` instead.
  </Accordion>
</AccordionGroup>

## Serving volume and performance

Serving is not metered and not billed today, and there are no published latency or availability
targets. If you are planning to put Livry on the render path of something high-traffic, talk to us
about it rather than inferring headroom from this documentation.

## Telling us

If something here is blocking you, that is useful information and it changes what gets built next:
[support@livry.dev](mailto:support@livry.dev).


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