Headless
So far the docs have assumed the main path: a generated app that renders from the manifest via the platform runtime. There's a second path, for when you already have a bespoke site and want just some Fayz capabilities inside it — not the whole shell. That's headless mode.
This page describes the concept and the shape. Headless packaging for plugins is landing alongside the website plugins (blog, payments, public booking) — which is why the concrete imports aren't shown here yet: they'll only be published once the packages export the subpath. Experimental
The idea
On the main path, Fayz owns the page: the shell, the menu, and the layout come from the scaffold, and you wire up plugins. On the headless path, you own the page — a bespoke site in any framework — and you import from a plugin only what you need: the data and components of one capability, without the shell.
This is for marketing sites that want, say, a blog and a booking button embedded in their own design, without adopting the admin's navigation.
The shape: a { manifest, Provider } bundle + subpaths
The packaging plan is for each website-facing plugin to expose a headless bundle with two pieces:
manifest— the samePluginManifestthat describes the capability (the contract doesn't change between the two paths).Provider— a React provider that injects the plugin's context (data provider, tenant) into your tree, so your components can consume it via hooks.
Each capability's component is served from a dedicated package subpath (e.g. the public booking piece, separate from the admin piece). You mount the Provider once at the root of your site and use the headless components wherever you want in your own layout.
Why the contract is the same
Here's what makes headless worth it: a plugin isn't rewritten to become headless. The same PluginManifest that runs in the admin shell runs inside your site — the only thing that changes is who assembles the page. It's the same symmetry as the customization ladder: the plugin declares the capability, and the host (the Fayz shell or your site) decides how to render it.
In the meantime
If you need a bespoke site with Fayz capabilities today, the supported path is a generated app with a storefront scaffold and pages recomposed via blocks (levels 3–6 of the customization ladder). Full headless mode — importing a plugin bundle into a project that's entirely your own — arrives with the website plugins.
Next: understand the core library all these paths share in Data model.