Skip to main content
Livry is early. This page is the list we would want to read before committing an integration to a date.
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.

​
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.

​
Machine credentials are not issuable

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.

​
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.

​
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.
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.
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: There is no way to be notified when a publish finishes — poll the pinned URL instead. See Caching.

​
Limits of the model, by design

These are not gaps and will not change:

​
Smaller sharp edges

Its version number is the Theme version its overrides answer. A second publish against the same Theme version answers 409. Publish the Theme first.
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.
A DTCG document relying on either imports with tokens missing, and nothing warns you. Use aliases.
They have no framework/library pair, and a Theme serves only what its pairs need. Add one on the Integration tab and republish.
Two creates at the same instant can leave a Team one over its allowance.
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.
The created resource’s id is in the body.
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.

​
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.