Developer

Build landing pages with your own tools

Build a landing page in a folder with Claude Code, Codex or any static-site build, then apply, preview, deploy, roll back and test it with Apex.

Simple terms

You build the page. Apex keeps its versions, tracks its goals, deploys it, and tests one version against another.

A landing page built outside Apex lives in a checkout folder. Any tool can build it: Claude Code, Codex, a Vite or Astro build, or plain HTML. Apex stores every applied version, serves the deployed one, injects the shop's Apex snippet, and creates the goals the page declares.

The workflow

bash

apex landing-pages create --name "Fall sale" --out ./fall-sale   # or: apex landing-pages pull <id> --out ./fall-sale
# build ./fall-sale/index.html and its assets
apex landing-pages plan ./fall-sale              # what would change
apex landing-pages apply ./fall-sale --yes       # a new version, plus a signed preview link (24 hours)
apex landing-pages deploy ./fall-sale            # live at https://<shop>.apex-page.com/fall-sale
apex landing-pages rollback ./fall-sale --version 1
apex landing-pages experiment ./fall-sale --control 1 --variant 2   # a draft split test; start it in the dashboard

The same steps exist as MCP tools (create_landing_page, pull_landing_page, plan_landing_page, apply_landing_page, preview_landing_page, deploy_landing_page, list_landing_page_versions, rollback_landing_page, create_landing_page_experiment), and the domain commands as list_landing_page_domains, claim_landing_page_domain, register_landing_page_domain, check_landing_page_domain and remove_landing_page_domain. See the MCP tool reference.

The checkout folder

Path	What it is
`index.html`	The page. Required at the root.
`assets/…` and other files	Stylesheets, scripts, images and fonts. At most 300 files and 25 MB in total.
`apex-landing-page.json`	The manifest: name, slug, host, path, snippet, shop hosts, goals and experiment.
`context/`	Read-only context from Apex: brand kit, catalog, offers, reviews, and the idea the page tests. Never uploaded.
`.apex/landing-page.json`	The marker that ties the folder to its page and pulled version.

Allowed file types: html, css, js, mjs, json, svg, png, jpg, jpeg, webp, avif, gif, ico, woff, woff2, txt, xml and webmanifest. Build with relative asset URLs (Vite base: "./"): Apex serves assets from a versioned path.

apex-landing-page.json

json

{
  "name": "Fall sale",
  "slug": "fall-sale",
  "path": "/fall-sale",
  "snippet": true,
  "shop_hosts": ["shop.example.com"],
  "goals": [
    { "key": "buy", "name": "Buy button", "type": "click", "selector": "a.buy" },
    { "key": "signup", "name": "Newsletter", "type": "custom", "event_name": "newsletter_signup" }
  ]
}

host: a domain the shop holds. Leave it out to deploy to the shop's instant host.
path: where the page lives on the host. Default: /<slug>.
snippet: Apex adds the shop's snippet to the page when it serves it. Turn it off only when the page loads the snippet itself.
shop_hosts: links to these hosts carry the visitor's identity, so a purchase on the shop counts for the page's test. Default: the shop's install domains.
goals: each goal is created on the shop by its key and named <slug>: <name>. A changed goal is updated when the version that changes it is deployed. A removed goal is kept.
experiment: optional control and variant version numbers.

Where a page goes live

Instant host. Every shop has its own address on apex-page.com: https://<shop>.apex-page.com/<path>. The label comes from the shop's domain (shop.example.com becomes shop-example-com). It is assigned at the shop's first deploy and never changes, also when the shop's domain changes later. No DNS setup is needed. A shop must be live on its own domain to deploy here.

Claimed domain. Set host in the manifest, or pass --host, to deploy to a domain the shop holds, such as offers.shop.example.com. Claim a client's hostname with apex domains claim offers.shop.example.com (add the CNAME it prints, then apex domains status offers.shop.example.com), or register a new domain on the Drip account with apex domains register.

A host on apex-page.com other than the shop's own address is refused.

Cookies on apex-page.com

Each shop's pages run on their own subdomain, so one shop's pages cannot read another shop's storage. On apex-page.com every Apex cookie is a host-only __Host- cookie, such as __Host-drip_uid for the visitor id. Another subdomain cannot set a __Host- cookie, and Apex reads no other cookie there, so a cookie another shop's page places on the parent domain never reaches Apex. Pages on apex-page.com never share cookies with the Apex dashboard.

If an experiment on an apex-page.com page targets visitors by a cookie, the page must set that cookie with the __Host- prefix (for example __Host-plan=pro; Path=/; Secure); the targeting rule still names it plan.

Rollback and experiments

rollback deploys an older version to the page's current address. experiment creates a draft test that splits the live page between two versions; start it in the dashboard. While a test splits the page, a deploy or rollback keeps serving the test's two versions; the deployed version takes over when the test ends.