# Headless

Até aqui a documentação assumiu o caminho principal: um app gerado que renderiza a partir do manifesto pelo runtime da plataforma. Existe um segundo caminho, para quando você já tem um site sob medida e quer só **algumas** capacidades do Fayz dentro dele — não o shell inteiro. É o modo headless.

{% callout type="info" %}
Esta página descreve o **conceito e o formato**. O empacotamento headless dos plugins está chegando com os plugins de website (blog, payments, agenda público) — por isso as importações concretas ainda não são mostradas aqui: elas só serão publicadas quando os pacotes exportarem o subpath. {% badge status="experimental" /%}
{% /callout %}

## A ideia

No caminho principal, o Fayz é dono da página: o shell, o menu e o layout vêm do scaffold, e você liga plugins. No caminho headless, **você** é dono da página — um site bespoke em qualquer framework — e importa de um plugin só o que precisa: os dados e os componentes de uma capacidade, sem o shell.

Isso serve para sites de marketing que querem, por exemplo, um blog e um botão de agendamento embutidos no design próprio, sem adotar a navegação do admin.

## O formato: um bundle `{ manifest, Provider }` + subpaths

O plano de empacotamento é que cada plugin voltado a website exponha um bundle headless com duas peças:

- **`manifest`** — o mesmo `PluginManifest` que descreve a capacidade (o contrato não muda entre os dois caminhos).
- **`Provider`** — um provider React que injeta o contexto do plugin (data provider, tenant) na sua árvore, para os seus componentes consumirem via hooks.

O componente de cada capacidade é servido por um **subpath** dedicado do pacote (ex.: a peça pública de agendamento, separada da peça de admin). Você monta o `Provider` uma vez na raiz do seu site e usa os componentes headless onde quiser no seu próprio layout.

## Por que o contrato é o mesmo

O ponto que faz o headless valer a pena: um plugin não é reescrito para virar headless. O mesmo `PluginManifest` que roda no shell do admin roda dentro do seu site — muda só **quem monta a página**. É a mesma simetria da escada de personalização: o plugin declara a capacidade, e o host (o shell do Fayz ou o seu site) decide como renderizá-la.

## Enquanto isso

Se você precisa hoje de um site sob medida com capacidades Fayz, o caminho suportado é o app gerado com um scaffold `storefront` e páginas recompostas via blocos (níveis 3–6 da [escada de personalização](/pt-BR/docs/apps/personalizacao)). O modo headless completo — importar um bundle de plugin dentro de um projeto totalmente seu — chega com os plugins de website.

---

Próximo: entenda a biblioteca core que todos esses caminhos compartilham em [Modelo de dados](/pt-BR/docs/dados/modelo).