Fragment Based Deployment

Build editable pages in StaticPagesApi, then deploy focused React fragments into overlays for WordPress, Shopify, Rails, and custom sites.

What fragment based deployment means

Fragment based deployment separates the page from the interactive bits. Marketing teams keep the page, copy, metadata, images, rows, and layout editable in StaticPagesApi. Developers keep focused React fragments in a component repo and deploy those fragments into raw HTML overlay targets.

The result is a page that stays editable while interactive forms, calculators, demos, search tools, booking widgets, or product modules can ship through a developer workflow.

  • Use StaticPagesApi for page structure, editable content, and publishing destinations.
  • Use React for isolated interactive fragments that need code review, tests, or CI.
  • Use component deploy targets to update the direct overlay section or any row in its selected fragment stack.
  • Use webhooks and integrations to publish the final static HTML wherever the business already runs.

Who owns what

The core workflow is intentionally split between marketers and developers.

  • Marketing owns page copy, page sections, row content, images, SEO fields, categories, and destination choices.
  • Developers own React component code, build scripts, API credentials in CI, and deployment manifests.
  • StaticPagesApi connects the two by giving each fragment a stable deployment key.
  • A page can contain many fragments, and each fragment can deploy independently.

Destination flow

After a fragment deploy updates the overlay raw HTML, StaticPagesApi renders the page and can publish it through the same destinations as any other page.

  • WordPress: export static HTML to a WordPress plugin endpoint.
  • Shopify: export landing or campaign HTML to a Shopify integration endpoint.
  • Rails: publish into a Rails receiver, route, engine, or internal site.
  • Custom sites: send HTML to any webhook receiver, S3 pipeline, CDN deploy, or bespoke build system.
  • One page can be edited once and exported to as many publishing sites as the organization plan allows.

React component repo

A component repo can hold many independent deployable fragments. Each component has its own directory and manifest, and each manifest points at a StaticPagesApi deployment key.

static_pages_api_react_component_deploy/
  components/
    newsletter-signup/
      component.jsx
      manifest.mjs
    pricing-calculator/
      component.jsx
      manifest.mjs
  scripts/
    build.mjs
    deploy.mjs
  dist/
    newsletter-signup.html
    pricing-calculator.html

Manifest and deploy key

The manifest is the contract between a React fragment and the StaticPagesApi overlay target. The deployTargetKey must match the Deployment key saved on the section or row.

export default {
  name: "newsletter-signup",
  output: "newsletter-signup.html",
  deployTargetKey: "newsletter-signup-page-16"
};

Build and deploy

Build and deploy one fragment when only one overlay changed. Build and deploy all fragments when the whole component repo is released.

npm run build -- newsletter-signup

STATIC_PAGES_API_URL="https://staticpageapi.com" \
STATIC_PAGES_API_TOKEN="YOUR_API_TOKEN" \
npm run deploy -- newsletter-signup

# Or release every fragment with a manifest:
npm run build
STATIC_PAGES_API_TOKEN="YOUR_API_TOKEN" npm run deploy

Page composition pattern

A common pattern is an overlay section where StaticPagesApi owns one side and the React repo owns the other.

  • Set type_of to overlay and overlay_layout to split_pane.
  • Use section_content for the editable marketing side.
  • Use a raw_html row for the React fragment side.
  • Set a deployment key on that raw_html row.
  • Keep the exported fragment small: semantic markup, a wrapper, and only the behavior script it needs.

Operational guidance

Treat fragment deployment like any production deploy path.

  • Use one API token per repo or CI workflow.
  • Store STATIC_PAGES_API_TOKEN and STATIC_PAGES_API_URL in CI secrets.
  • Review generated raw HTML before giving a pipeline deploy credentials.
  • Use webhook delivery history to verify the final page reached WordPress, Shopify, Rails, or a custom receiver.
  • Keep pages editable in StaticPagesApi instead of turning the whole page into a raw HTML blob.