Build your site on the MooverApp API
Your store, assembled by API calls
Accounts, websites, pages and blocks, blog, media, themes, views and settings — every one of them a resource with the same five methods. The admin interface is written against exactly this surface, so there is nothing it can do that your code cannot.
Ten steps from an empty account to a page on a live domain, as one script you can run.
Pages, blocks, menus, blog, media, themes and per-language views — the whole reference, generated from the running service.
Every site the platform renders ships a read API, Markdown twins, an MCP endpoint and a discovery catalog.
What you can rely on
Every surface follows one standard: five standard methods on named resources, snake_case
bodies, the same paging, filtering and ordering parameters on every list, one error shape,
etag/If-Match for concurrency, and an Operation to poll whenever the work outlives the
call. Learn it once on one resource and you can predict the next one — which is what
Concepts is for.
Why this page cannot go stale
This documentation is generated from the declarations the running service is built from, in the same build that produces the running service, and shipped by the same release. There is no synchronisation step to forget: the description of an endpoint and the code that answers it are one commit. Rename a field and the page describing it changes with it — or the build fails.
The requests in the guides are the same thing in the other direction: they are regions of one script that is executed, not an illustration typed into a page.