AI instructions

What to give an AI

Give the AI a short command with the StaticPagesApi base URL, an organization API token, and the page brief. The AI should read this page first, then follow the linked learning flow and live schema before creating content.

The docs explain how StaticPagesApi thinks. The schema tells the AI the current fields, enum values, section types, row types, and allowed payload shape. The API token scopes every request to the correct organization.

The prompt is only the starting point. Tell the AI what you want the page to feel like, who it is for, which offer or message matters most, and any sections, calls to action, or design references it should follow. After the AI creates a draft, use StaticPagesApi to upload real images, edit copy, move sections, reorder rows, and polish the page. The system is intentionally human-editable and AI-assisted, not a one-shot page generator.

• Canonical AI starting point: /docs/ai-instructions
• Required template training: /docs/ai-template-generation
• Schema: GET /api/v1/schema
• Owned templates: GET /api/v1/templates
• Default template library: GET /api/v1/template_library
• Blueprint creation: POST /api/v1/page_blueprints
• Authentication: Authorization: Bearer YOUR_API_TOKEN

Tiny copyable prompt

Paste this short command into ChatGPT, Codex, Claude, or any AI client that can read URLs and call your API.

You are building editable pages in StaticPagesApi.

Use this base URL: https://staticpageapi.com
Authenticate API calls with: Authorization: Bearer STATIC_PAGES_API_TOKEN

First read https://staticpageapi.com/docs/ai-instructions, https://staticpageapi.com/docs/ai-page-generation, and https://staticpageapi.com/docs/ai-template-generation, then follow the required learning flow exactly. Fetch GET /api/v1/schema, GET /api/v1/templates, and GET /api/v1/template_library before building. Use POST /api/v1/page_blueprints for new pages and keep pages draft unless I ask to publish. Never create or assign tags; tags are user-managed. For generated landing pages or marketing pages, end the page with an actual footer Liquid template from the owned templates or default template library, such as section_footer_columns, section_footer_newsletter, or section_footer_directory, instead of a generic text/raw HTML footer. The footer must render 3-4 populated columns on desktop, with one compatible Liquid row per column and every link stored as an ordered action with a meaningful label and verified URL. When revising existing content, update existing sections with PATCH /api/v1/sections/:section_id and existing rows with PATCH /api/v1/rows/:row_id; do not replace an entire section or row just to change copy, styling, template_data, order, or settings.

Build this page: PAGE_BRIEF_HERE

How to direct the AI

A better brief produces a better first draft. Include the audience, product or service, desired tone, key proof points, must-have sections, calls to action, and any visual direction such as modern, editorial, minimal, premium, playful, or operational.

Expect to refine the draft. StaticPagesApi keeps pages editable so you can upload final images, swap placeholders, drag sections into a better order, adjust row content, tune CTAs, and ask the AI to patch specific sections or rows when you want help revising.

• Use the AI for structure, copy options, template choices, and first-pass layout.
• Use the editor for final images, ordering, brand judgment, and small visual polish.
• For revisions, ask the AI to update existing section and row IDs instead of replacing whole records.

Tiny prompt example

This is the same prompt with example values filled in.

You are building editable pages in StaticPagesApi.

Use this base URL: https://staticpagesapi.com
Authenticate API calls with: Authorization: Bearer spapi_abc123

First read https://staticpagesapi.com/docs/ai-instructions, https://staticpagesapi.com/docs/ai-page-generation, and https://staticpagesapi.com/docs/ai-template-generation, then follow the required learning flow exactly. Fetch GET /api/v1/schema, GET /api/v1/templates, and GET /api/v1/template_library before building. Use POST /api/v1/page_blueprints for new pages and keep pages draft unless I ask to publish. Never create or assign tags; tags are user-managed. For generated landing pages or marketing pages, end the page with an actual footer Liquid template from the owned templates or default template library, such as section_footer_columns, section_footer_newsletter, or section_footer_directory, instead of a generic text/raw HTML footer. The footer must render 3-4 populated columns on desktop, with one compatible Liquid row per column and every link stored as an ordered action with a meaningful label and verified URL. When revising existing content, update existing sections with PATCH /api/v1/sections/:section_id and existing rows with PATCH /api/v1/rows/:row_id; do not replace an entire section or row just to change copy, styling, template_data, order, or settings.

Build this page: A draft landing page for a local med spa offering hydrafacials, laser hair removal, and membership packages. Use a strong hero, services section, proof, FAQ, and closing CTA.

Required learning flow

Before creating or editing any page, the AI should read the linked learning material, then fetch the live API schema and template lists. The linked docs hold the longer guidance so customers do not have to paste a giant prompt into chat.

Treat worked examples inside the AI page generation guide as training examples, not copy-paste templates. Learn their decision patterns: choose native sections and rows first, use raw_html only for truly custom pieces, use Liquid templates for reusable custom layouts, preserve editable content, choose media-capable components when assets exist, and verify spacing, overlap, and clipping risks.

• Read /docs/ai-page-generation for the end-to-end page building workflow and worked examples.
• Read /docs/ai-template-generation so the AI knows how to create, copy, and attach Liquid templates for both sections and rows through the API.
• For generated landing pages and marketing pages, use an actual Footer Liquid section template from owned templates or GET /api/v1/template_library for the final footer band. Prefer section_footer_columns, section_footer_newsletter, or section_footer_directory when available. Render 3-4 populated columns with one compatible Liquid row per column, and store every link in that row's ordered actions collection.
• Read /docs/ai-prompts for component-specific prompt patterns.
• Read /docs/section-types for section layout choices.
• Read /docs/row-types-and-components for row/component choices.
• Read /docs/analytics-events when the page should send customer-owned analytics events from exported CTAs or links.
• Read /docs/component-deploy-targets and /docs/spa-section-overlays when deploying widgets, React fragments, overlays, or trusted raw HTML targets.
• Then call GET /api/v1/schema, GET /api/v1/templates, and GET /api/v1/template_library.
• If docs and schema differ, follow the live schema for fields and enum values.

Liquid template rules

Use Liquid templates when a layout needs custom HTML, CSS, or JavaScript but the content should remain editable in StaticPagesApi.

• Create templates with POST /api/v1/templates.
• Use templateable_type Section for full page bands.
• Use templateable_type Row for repeated cards, slides, FAQ items, stats, custom row layouts, or reusable subcomponents.
• Include scoped template_html, template_css, and optional template_js.
• Scope CSS under a unique root class. Do not write broad selectors like body, h1, p, .container, .card, or .btn.
• Declare editable values in field_schema.
• Use default_data for fallback editable values and sample_data for previews.
• Use Liquid variables such as section.header, section.subheader, section.body_html, section.data.*, rows, rows_by_group, rows_by_column, row.header, row.subheader, row.body_html, and row.data.*.
• When rendering editable CTA or link anchors, include the matching analytics attribute string, such as section.actions[0].analytics_attributes, section.actions[1].analytics_attributes, row.actions[0].analytics_attributes, row.actions[1].analytics_attributes, or row.actions[0].analytics_attributes. It also preserves link_target behavior for existing templates.
• After creating or copying a template, create or update a section or row with template_id and pass editable values through template_data. Use either type_of for a built-in renderer or template_id for a Liquid renderer, not both.
• If a section uses a Liquid template_id, every row inside that section must also use a Liquid row template_id. In the section template, render those child row templates with row.rendered_html.
• Do not use one page-sized Liquid template for the whole page. Create reusable templates for individual layout patterns.

Minimal API sequence

An AI client should use this sequence before it creates anything.

curl https://staticpageapi.com/docs/ai-instructions
curl https://staticpageapi.com/docs/ai-page-generation
curl https://staticpageapi.com/docs/ai-template-generation
curl https://staticpageapi.com/docs/ai-prompts
curl https://staticpageapi.com/docs/section-types
curl https://staticpageapi.com/docs/row-types-and-components
curl https://staticpageapi.com/docs/analytics-events

curl https://staticpageapi.com/api/v1/schema \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Accept: application/json"

curl https://staticpageapi.com/api/v1/templates \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Accept: application/json"

curl https://staticpageapi.com/api/v1/template_library \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Accept: application/json"

curl https://staticpageapi.com/api/v1/page_blueprints \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d @blueprint.json

Common task prompts

These are useful prompts for users who do not want to write a technical brief.

• Create a draft landing page for this service. Use the schema first, vary the section and row types, and include a strong hero, proof, FAQ, and closing CTA.
• Recreate this Figma mockup. Create reusable Liquid templates for layout patterns the built-in section and row renderers cannot express, define field_schema for every editable template value, then create sections and rows that use template_id and template_data instead of type_of.
• Revise this page by adding more vertical spacing between sections using section_classes, then add a pricing/workflow comparison section.
• Add a reusable navbar section to this Page Shell. Page Shells also support every other built-in section type and organization-owned Liquid section template.
• Create an SEO page targeting these search terms. Keep it draft, include metadata, and use image-capable components where images are available.
• Export this page body-only because my receiving site already provides the head and layout.

Safety rules for AI clients

These rules keep generated pages compatible with the app and easier for humans to edit later.

• Call GET /api/v1/schema before generating payloads.
• List owned templates with GET /api/v1/templates and default templates with GET /api/v1/template_library before creating new ones. Copy close defaults with POST /api/v1/template_library/:id/copy.
• Do not send organization_id; the API token scopes the request.
• Respect trial limits. Trial accounts last seven days, can create three pages, and can export as many times as needed. Prefer editing existing drafts during experiments.
• Treat HTTP 402 responses as subscription or trial-limit responses. Do not keep retrying the same write request with small payload changes.
• Use built-in section and row types before using raw_html. Use Liquid templates when the layout must be custom but the content should remain editable.
• For general page requests, mix built-in section and row type_of values with 1-3 owned or copied Liquid-backed sections/rows so the page has reliable structure and custom visual polish from the first draft.
• End generated landing pages and marketing pages with an actual Footer Liquid template copied from owned templates or the default template library, not a generic text/raw HTML footer. Render 3-4 populated columns with one compatible Liquid row per column, and store every link in that row's ordered actions collection.
• Keep generated pages draft unless the user asks to publish.
• Use active only for sections and rows that should render.
• Verify rendered output after creation, especially media, spacing, CTAs, navbars, and collapsible rows.
• Use incremental section and row endpoints for revisions instead of replacing an entire page when only one component needs editing.