Expose your components via the Block Manifest
The editor needs to know which components on your site are editable and what props they accept. You do this by exposing a block manifest atGET /api/editor/blocks.
Using the built-in blocks (quickest start):
createEditorApiHandler() automatically builds the manifest from the 20 built-in block types and mounts the draft / pages / publish routes alongside it under /api/editor/*. The editor and AI planner read this manifest to understand what blocks exist, what fields they have, and what values are valid.
Using your own custom components:
If your site has its own component library, you define a custom manifest describing your block types and their props schemas. See Custom Blocks for the full guide, including:
- How to define a
BlockManifestwith JSON Schema-basedpropsSchemafor each component - How to wire it into the editor API route via
getManifest() - How to mix your custom blocks with the built-in ones
- How field types (image, text, list, enum) are inferred from your schema
Required env vars
- Site:
DRAFT_MODE_SECRET
- Editor:
VITE_SITE_ORIGINVITE_SITE_DRAFT_SECRET(same value as siteDRAFT_MODE_SECRET)
Iframe bootstrap URL (enter draft mode)
Pattern:pathWithQuery is your target site path plus context query params, for example:
Exit draft mode (view live page)
Pattern:Minimal behavior checks
GET /api/editor/blocksreturns valid block manifest JSON.GET /api/editor/pagesreturns{ pages: [...] }with published pages.- Wrong secret returns
401from/api/editor/draft. - Valid secret redirects and sets draft cookie.
/api/editor/draft/disableclears draft cookie and redirects.- Same page renders published content when draft cookie is absent.
Contract self-check (recommended before onboarding)
Run these in the site project:- manifest route returns
versionand non-zero block count - Content Studio header shows
Manifest(notDegraded)