Mini Programs: one site's content, rendered natively in WeChat

A Zeso site is one data plane: collections, typed rows, one publish gate. It now has two rendering surfaces — the web, and a native WeChat Mini Program reading the same published content. This page states exactly what shipped, because the honest list is shorter than a marketing version would be, and the boundary between the two surfaces is the part a site owner needs to know.

What shipped: one JSON document

Every site's live content is available as a single JSON document at https://{your-domain}/api/miniprogram. One request carries the whole site: its collections, their typed field definitions, and every live row, exactly as publish promoted them.

The document carries the site's content version — the same counter the dashboard shows as v1, v2, v3; the mechanism is explained in the caching and content versions article. A client that sends that version back with its next request receives an empty 304 response until the next publish, so a pull-to-refresh costs nothing when nothing has changed. That version check is the only freshness mechanism. There is no separate "sync to mini program" step, and therefore nothing to forget.

Rich text arrives as plain paragraph blocks, never HTML. The Mini Program renderer is never asked to interpret markup the platform has not vetted — the same rule the web renderer enforces by escaping, applied one layer earlier. A paragraph is a paragraph on every surface.

The rules it inherits

Three rules carry over from the web lane unchanged, because they belong to the data plane rather than to any renderer:

• Live only. The feed is a public read of live rows. Staged and draft

rows do not exist as far as a Mini Program is concerned.

• Publish is the only promotion. Whatever publish promoted is what the

feed carries — the same gate, the same version bump, no second path.

• One site per document. The feed is served for your domain and carries

no other site's content.

The reference renderer

We ship a native WeChat Mini Program reference renderer at miniprogram-renderer/wechat/ in the repository. It is a starting point, not a finished product: a site owner points it at their own domain, whitelists that domain as a request domain in the WeChat Mini Program console, and opens the project in WeChat DevTools. It fetches the bundle, maps each typed field to a native component, and renders what publish promoted, with built-in defaults.

The renderer is native on purpose — fewer moving parts in platform review, and one less framework between your content and the screen.

One detail of the field mapping is worth knowing before you rely on it: the feed carries fields typed exactly as stored. Text is text, numbers are numbers, and an image arrives as a URL string — the renderer ships a load-failure placeholder, so a broken image is a content problem to fix in the row, not a renderer crash. A date field is displayed verbatim rather than re-parsed into a format the platform never promised.

What does not exist yet

Stated as plainly as what did ship:

• No Studio integration. The builder's dashboard has no Mini Program

panel yet.

• No one-click publish to WeChat. Deploying the renderer is still a

manual step taken by the site owner.

• No Douyin build in the box. The Douyin port is specified and follows.
• No theme customization. The renderer renders what publish promoted,

with built-in defaults; theme tokens are reserved for a later phase.

The renderer renders what publish promoted. Nothing more — and, the point of listing the gaps, nothing pretended.

Web render and Mini Program render, side by side

Read the table as two columns of one story: everything above the presentation row is shared, because content, the publish gate and version freshness are properties of the data plane. Everything at and below it differs, because a template library, a request-domain whitelist and a review process belong to the surface, not to the content.