The platform APIs and your demo
Your template demos itself
Every template gets a live demo: a prospective buyer walks the public site, the customer portal and the staff dashboard as they would look for their trade, before they spend anything.
You do not build that demo, and you do not write a line of code for it. If your template calls the platform's own APIs, the demo works — including the parts that normally need a real backend.
What the platform does for you in a demo
| What happens | In production | In a demo |
|---|---|---|
| Reads | real data | real data from the demo business |
| Writes | persisted | run for real, then rolled back |
| Success notifications | shown | shown, identically |
| Emails and texts | sent | reported as sent, nothing leaves |
| Payments | charged | refused outright |
| What the visitor typed | saved | held in the tab, cleared when it closes |
The important row is the third. When a visitor fills in a form in your demo and the API returns success, the same toast fires that fires in production — because it is the same code path. The platform knows nothing really went out; your template does not have to.
There is no if (demo) for you to write. No demo flag to read, no second code path, no
mock endpoint to point at. A template that works in production works in its demo, and
that is the only version of it you maintain.
Why this is worth caring about
Using the platform-native APIs is not a style preference. It is the difference between a template that behaves and one that fights you:
It passes review. The checks look at what your template actually does. Blocks wired to the platform's own APIs are understood by them; something hand-rolled around the outside is the thing a reviewer has to stop and reason about.
It is the fastest version. Platform calls are rendered, cached and batched by machinery that is already tuned — and most of your template is static HTML with no client runtime at all. Fetching the same data yourself means shipping code to do it, on every page, forever.
It keeps working. When the platform changes, the native path is what gets migrated, and you are told when a template needs updating. Something built around the side of it is yours to notice and yours to fix.
It is less work. The demo, the notifications, the stored state and the cleanup are all already written. The cheapest template to build is the one that asks the platform to do the things the platform already does.
What "native" means in practice
- Use a contact form or saved form block rather than posting somewhere yourself.
- Use sign in / account status rather than building your own session handling.
- Read content from collections and site data rather than embedding it in the page, so a buyer can edit it without editing your markup.
- Reference files you upload with the template rather than URLs on your own host.
Every one of those is also a rule the import validator enforces, which is not a coincidence — the safe path and the supported path are deliberately the same path.
The one thing to keep in mind
Your demo runs against a shared demo business with its own staff, customers and history, supplied by the platform and identical for every template. You provide what is specific to the trade; the people and the activity around it are ours.
That is why you cannot name a collection staff or conversations — those already
exist in every demo, and the data behind them is not yours to define. See
Collections and site data.