# 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.

{% callout type="info" %}
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. {% badge status="experimental" /%}
{% /callout %}

## 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 same `PluginManifest` that 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](/en/docs/apps/customization)). 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](/en/docs/data/model).