A template lives in the database, not in a repository, and it is rendered live on every request. So shipping a change is just saving the record. The parts worth knowing are how to check your Liquid before you save, and how the caches in front of the renderer decide when a visitor sees the new version.

Validate a template

Before you save, parse-check the body with the same engine that will render it. POST /api/v1/templates/validate takes a template body and returns the syntax errors the real parser finds, catching malformed tags and output that a client-side check would miss.

It is available to a signed-in user with a role above 2 (role 3 and up). A caller without that role gets 403. Send the source under a body field:

{ "body": "
{{ page.title }}
" }

A body that parses cleanly comes back with ok true and an empty error list:

{ "data": { "ok": true, "errors": [] }, "state": "ok" }

A body with a mistake, for instance a tag that is never closed, comes back with ok false and one error describing it:

{ "data": { "ok": false, "errors": [ { "message": "tag 'if' not closed", "line": 1 } ] }, "state": "ok" }

Each error is a message and a line. The message is the parser's own wording; the line is a 1-based line number, or null when the parser cannot place it. Two details shape how you use this:

• One error per call. The parser stops at the first syntax error, so at most one comes back. Fix it, validate again, and the next error surfaces. Repeat until ok is true.
• It parses, it never renders. Validation only builds the template, it does not run it, so side-effecting tags such as {% fetch %}, {% prefetch %} and {% collection %} never fire during a check. An empty or whitespace-only body is treated as valid.

Validation checks syntax, not meaning. It confirms the template parses; it does not confirm a filter exists or a variable is set. Those surface at render time, and in Standard mode an unknown tag is left in place and logged rather than dropped, which is the other half of catching mistakes. See Render modes.

Save the template

Saving writes the body back to the record. Create a template with POST /api/v1/templates, which any signed-in user may do; update an existing one with PUT, PATCH or POST to /api/v1/templates/:uid, which the template's own author or a role 3+ user may do. The save updates the body along with the title, permalink and type you send.

The moment a template is saved, the server purges the caches tied to it, so the next request renders the new body rather than a cached copy of the old one. What exactly gets purged, and the one case where a change can lag, is the caching model below.

Caching and purging

Rendered pages sit behind a short cache. An anonymous page render is held in memory for about 30 seconds. Authenticated requests and preview requests are never cached, which is why, signed in as the author, you usually see your edit immediately, while an anonymous visitor sees it once the entry is refreshed or purged.

A save does not wait for that 30 seconds to elapse. It purges by permalink:

• A page-bound template (one with a permalink) purges the cached page, the content lookup and the template-resolution entries for that exact path, so the change is live on the next request to it.
• A shared template with no permalink of its own, a layout or a partial many pages pull in, purges the site's page and template caches wholesale, because the edit can affect any page that composes it.

So the practical picture is simple. A correct save is live for the next visitor at once, because the purge reconstructs the exact cache key. In the worst case, a path the purge does not reach, the change still appears on its own within about a minute as the short page cache rolls over. Behind that page cache, the lookups that resolve a path to a template are cached for a few minutes, so a brand-new permalink can take a moment to become discoverable, but an edit to an existing page is purged directly and does not wait.

The full resolution and meta pipeline behind these caches, including how a path is matched to a template or post, is covered in The render pipeline.