ai.spideriq/publish

Create a DRAFT changelog entry. `version` must be unique for the brand (e.g. "v2.10.0"); a duplicate returns 409. `body` is a Tiptap JSON document. Publish it afterwards with changelog_publish.

List your brand's changelog entries (version, title, status, published_at). This IS the built-in CHANGELOG content type — a /changelog route, RSS+Atom feeds, and dashboard editor already exist; you do NOT need to build a changelog. Note the tool naming: changelog_list / changelog_create / changelog_publish use a `changelog_` prefix (NOT `content_*_changelog_entry`). An empty list means zero entries created yet, not a missing feature. Use this to discover an entry's UUID before publishing it via changelog_publish. Optionally filter by status (draft/published/archived).

Publish a changelog entry (status → published). It appears on the public /changelog timeline + RSS/Atom feeds and, on the first publish, fires the changelog.published notification to subscribers. Reversible (no dry_run gate). Pass the entry UUID from changelog_list.

Check the status of a PAT access request. Returns 'pending', 'active', 'denied', 'expired', or 'revoked' (matches the backend PATRequestStatus enum). Once status==='active', the token is saved to ~/.spideriq/credentials.json automatically. Multi-brand approvals save one entry per workspace under client_id, with the first aliased as 'default' so existing tools (upload_local_file, etc.) keep working without --workspace.

Roll a component back to an earlier version's content. Creates a new published version (so the forward audit trail stays intact) and repoints every consuming page to it. When to use: - component_update_and_propagate went wrong and you need to unroll it - You want to revert to a known-good version without manually re-entering the old HTML/CSS - You want staged rollback — pass pages=["home"] to only revert the home page's pin How it works: 1. Call with dry_run=true — returns a confirm_token for the rollback action 2. Inspect preview; if right, call again with confirm_token 3. Service fetches target_version's content, creates a new published version with a fresh semver (bumped from the CURRENT version, default patch), and updates consuming pages' blocks to pin it 4. Block-level page content renders live on next request — no tenant deploy needed Pairs with component_update_and_propagate — the gate actions are distinct ("component_rollback" vs "component_update_and_propagate") so a token issued for one can't be consumed by the other.

Update a component's HTML/CSS/props/etc. AND repoint every consuming page to the new version, in one atomic call. When to use this instead of component_update: - The component is referenced from multiple pages and you want all of them to pick up the change - You want a single confirm_token covering the component + all page mutations (instead of one per page) - You want staged rollout — pass `pages: ["home"]` to update the component everywhere but only repoint the home page; other pages keep referencing the old version How it works: 1. Call with `dry_run: true` — returns `affected_pages` (what would change) + a `confirm_token` 2. Inspect the preview; if it's right, call again with `confirm_token: "cft_..."` 3. The service bumps semver (default patch; also supports minor / major), writes a new published component row, and UPDATEs blocks on every affected page's `content_pages.blocks` JSONB 4. Never auto-deploys the tenant KV. Block-level page updates render live via the content API on next request. Only run deploy_site_preview → deploy_site_production if you ALSO changed templates/theme/config. Pages filter semantics: - omit `pages` or set null → propagate to every consuming page (default, matches "update everywhere" intent) - pass `["home", "pricing"]` → only those pages get the new version pin; other consumers keep the old pin Field semantics: - At least one of html_template / css / js / props_schema / default_props / dependencies / name / description must be set - Inline `<style>` tags in html_template are rejected — put CSS in the css field - Dependencies validated against the Tier-3 CDN allowlist

Add a custom domain for your content site. Requires DNS verification after adding.

Apply a named layout preset to this client's site by writing layout/theme.liquid. When to use this instead of template_upsert: - You want "blank" (no header/footer), "minimal" (footer only), "landing" (header only), "chromed" (edge-to-edge main), or "default" layouts without writing Liquid yourself - You want to quickly test "what does the site look like with no global header?" - You don't have Liquid source for a layout — you just want a sensible starting point Available presets: "default" — header + main + footer (standard; matches bundled theme) "blank" — no header, no footer; full-page content "minimal" — footer only, no header "landing" — header only, no footer (marketing-landing chrome; from merged templates.ts duplicate, 2026-05-20) "chromed" — header + footer, but main is edge-to-edge (no container padding) After applying, customize individual sections with content_override_section().

Clone a page template's single page into the current tenant. Phase 11+12 gated. When to use: - A client/agent picked a page template and wants it added to their site - Building a funnel one page at a time (opt-in → thank-you → sales) from templates - You want a working page to ADAPT (edit copy/images/colors) instead of generating one How it works: 1. Reads the template's single source page from the SpiderIQ template-source tenant 2. Clones it into the current tenant as status='draft' with fresh block UUIDs 3. Applies any whitelisted theme settings the template carries Phase 11+12 flow: - First call with dry_run=true → {dry_run: true, preview, confirm_token, expires_at} - Inspect preview.pages_to_create (one page) - Second call with confirm_token=<token> → {pages_created, settings_applied} - The cloned page is a DRAFT — review, adapt, then publish with content_publish_page (and run content_visual_check against the published URL per Agent Trust 5.1). Same apply endpoint as content_apply_site_template; for a page template it clones exactly one page.

Clone a site template into the current tenant. Phase 11+12 gated. When to use: - New tenant just provisioned, agent wants to give them something to start from - Client picked a template from the gallery, agent wires it up - A/B testing different starter sites without rebuilding from blocks How it works: 1. Reads the template's source pages from the SpiderIQ-owned template-source tenant 2. Clones each into the current tenant as status='draft' with fresh block UUIDs 3. Copies navigation menus for header + footer (or whatever locations the template names) 4. Copies whitelisted theme settings keys (primary_color, body_text_color, etc.) 5. Bumps the template's applied_count for the leaderboard Phase 11+12 flow: - First call with dry_run=true → returns {dry_run: true, preview, confirm_token, expires_at} - Inspect the preview (pages_to_create, settings_keys_to_apply) - Second call with confirm_token=<token> → returns {pages_created, nav_updated, settings_applied} - Cloned pages are drafts, NOT published. Review + publish individually, or use content_deploy_site to push the lot to production CF edge.

Archive a component (removes from active use, keeps for reference). Phase 11+12: defaults to dry_run=true — review the preview and call again with confirm_token.

Walk every published page's blocks + navigation menus and validate internal links against the published-page roster + active redirects. Returns a structured report: - valid_count: number of links that resolved correctly - broken: [{path, source, reason}] — each broken link with its tree position - proposed_redirects: [{from, to, status_code}] — heuristic suggestions - known_redirects: [{from, to, status_code}] — already-active redirects The "source" field is JSONPath-shaped (e.g. "page:home/block[2].url", "navigation:header[3]") so callers can navigate straight to the offending position. Pre-push hook in the SpiderPublish extension uses this to surface broken links as inline diagnostics before the push fan-out runs. Use BEFORE deploying a content change to catch /en/* legacy URLs, renamed slugs, or post-merge orphans. Idempotent — safe to run repeatedly.

Create a blog author profile.

Create a blog category (supports parent_id for hierarchy).

Create a reusable UI component (auto-wrapped in Shadow DOM for CSS isolation). IMPORTANT — set `kind` at create time. Components without a `kind` are flagged as latent Tier 3 by the page auditor (rule `creation.kind_null_with_dependencies`) and excluded from marketplace_search. If you're shipping `dependencies` (gsap, chartjs, etc.) you almost always want `kind='interactive'` + `js_runtime='vanilla'`. See the `kind` field for the full taxonomy and the kind→js_runtime/block_type/sources invariant matrix. P5: pass `authoring_hints` to surface preferred_path / common_mistakes / must_set / must_not_set on the _rules envelope when other agents insert your component. The response carries an _audit block flagging latent traps (kind=interactive without js, global component without agent_meta, etc.).

Create a documentation page.

Create a new content page with blocks. Phase 11+12 Lock 4 gate is opt-in via dry_run/confirm_token. 🚨 BLOCK FIELD NAMES MATTER. The default theme's snippets read SPECIFIC `data.*` keys per block-type. Unrecognized keys are stored verbatim but render as empty markup (silent-blank-section trap). For the canonical per-block-type field list, call `template_inspect_block_fields(block_type)` OR read the `blocks` param schema below. Page auditor warns at read-time via `render.unused_field_in_default_theme` (rule shipped 2026-05-22). Most-confused mappings: hero → data.{headline, subheadline, cta_primary:{label,url}, cta_secondary:{label,url}, background_image_url, style} (NOT title/subtitle/cta_text/cta_url — those are silent-no-op) cta_section → data.{headline, description, cta_primary:{label,url}} stats_bar → data.{stats: [{value, label}]} rich_text → data.{html: '<raw html>'} OR data.{content: <Tiptap JSON doc>} (data.content as a STRING is rejected — use data.html instead) The `template` param selects which Liquid theme file renders the page (templates/<template>.liquid) — backend column is a free string, default 'default'.

Create a blog post (Tiptap JSON body, metadata, tags, author, categories, cover image, featured flag, SEO).

Register a NEW site-template catalog row so a built site/page becomes installable from the marketplace. Phase 11+12 gated. AUTHORING-ONLY. Auth: needs super_admin OR a PAT scoped to a marketplace-AUTHORING brand (clients.is_marketplace_authoring=TRUE — e.g. the demo-publish authoring account). A normal tenant PAT gets 403. The source pages must already exist (published) on source_client_id; this call just registers the catalog row that clones them on apply. PAGE TEMPLATES: set is_single_page=true AND pass exactly ONE source_page_slug (opt-in / thank-you / VSL / sales / …). The server enforces the single⇒1-slug CHECK. Omit is_single_page (or false) + pass multiple slugs for a whole-site template. Phase 11+12 flow: call once with dry_run=true → {dry_run, preview, confirm_token}, then again with confirm_token to actually create. Then content_update_site_template can attach a preview image, and the row appears in the Studio templates gallery (is_public=true).

Create a blog tag.

Soft-delete an author profile.

Delete a blog category.

Delete a UI component. Phase 11+12: defaults to dry_run=true — review the preview and call again with confirm_token to actually delete.

Archive/delete a documentation page (soft delete → archived). Children are left intact (a deleted section still anchors its descendants by parent_id). Phase 11+12: defaults to dry_run=true — review the preview and call again with confirm_token to actually delete.

Remove a custom domain from your content site.

Archive/delete a content page. Phase 11+12: defaults to dry_run=true — review the preview and call again with confirm_token to actually delete.

Delete a blog post. Phase 11+12 Lock 4 gate is opt-in via dry_run/confirm_token (defaults preserve immediate-delete for backward compat).

Delete a blog tag.

Check if your site is ready to deploy. Returns a checklist of what is configured (settings, domain, templates, pages) and what is missing. Call this BEFORE content_deploy_site — deploy will reject if blocking items are not resolved.

Deploy your site to Cloudflare edge. Uploads templates + config, site goes live in ~2-5 seconds. Phase 11+12: prefer `content_deploy_site_preview` + `content_deploy_site_production` for the safe two-step flow. This tool is kept for back-compat; set dry_run=true to preview, or pass confirm_token to consume a prior preview.

Phase 11+12 Stage 2 — issue a preview URL + confirm_token without deploying. Returns `{ preview_url, confirm_token, expires_at, preview: {...}, snapshot_hash }`. Call `content_deploy_site_production` with the returned confirm_token to actually deploy.

Phase 11+12 Stage 2 — consume a confirm_token from a prior `content_deploy_site_preview` call and run the real deploy (Lock 4). 410 on expired, 409 on already-consumed, 403 on mismatch.

Check the latest deploy status for your site.

Get your brand's documentation tree structure.

Insert a deep copy of one block into the same page. When to use: - Duplicating a CTA section to use in a different position on the same page - Cloning a tier-priced "feature card" inside a pricing-grid block - Building variations of the same section without rebuilding from scratch How it works: 1. Reads the source page; finds the block by id 2. Deep-copies the block JSON, regenerates the block's id (fresh UUID) 3. Inserts the copy at `position` ('before', 'after' default, or an int index) 4. Returns the updated PageResponse with the new block in place The page's status is unchanged (this doesn't unpublish a published page).

Duplicate a doc page. Copy lives as a sibling under the same parent node in the docs tree (same parent_id), with a fresh slug + full_path.

Duplicate a page. Returns the new draft. When to use: - Client wants a starting point that's similar to an existing page (faster than rebuilding from blocks) - You're applying a template by cloning master pages into the tenant (template gallery) - Internal A/B testing — fork a published page, edit copy, publish under a new slug How it works: 1. Reads the source page (must be owned by the caller's client; cross-tenant read refused 404) 2. Picks a fresh slug (`{original}-copy`, `-copy-2`, `-copy-3`, ... lowest unused) unless `new_slug` is provided 3. INSERTs a new content_pages row with status='draft', regenerated UUIDs on every block 4. Title gets " (Copy)" appended so the dashboard list shows it distinctly 5. Returns the full PageResponse Not gated — duplicates create new rows rather than overwriting state, so no confirm_token is required. Just call once and you get the new page.

Duplicate a blog post. Returns the new draft with a fresh slug. The body (Tiptap JSON), cover image URL, author, and tags all copy over. Status is forced to 'draft' regardless of the source's state.

Export a doc as a self-contained envelope: doc row (Tiptap body, SEO, full_path) + site settings + domains. Docs are prose-first, so there are no component bodies to inline (unlike content_export_page). format='json' (default) returns the JSON envelope; format='md' returns human-readable Markdown rendered from the body.

Export a doc OR page as pure, round-trippable Markdown. target='doc' renders the Tiptap body; target='page' renders the blocks with each component block serialized back to a `:::component{...}` directive. The text round-trips through content_import_markdown. (For the richer JSON export envelope — components inlined, settings, domains, audit — use content_export_doc / content_export_page instead.)

Export a page as a self-contained envelope: page row + every component referenced by page.blocks (full body inlined — html_template, js, css, props_schema, dependencies, agent_meta, kind, layouts) + site settings + domains + a PageAuditor walk (10 v1 rules: scroll-sequence empty frames, missing primary domain, page SEO holes, latent Tier 3 components, etc.). Use this instead of content_get_page when you need the FULL picture before editing — e.g. to understand what `vp-hero` actually is, or to surface broken sections before redeploying.

Get featured blog posts (public, no auth needed).

Get an author profile by ID.

Get the build status of a framework component (Tier 4). Returns build_status, build_error, bundle_url.

Get a UI component by ID (includes template, CSS, props schema).

Get a UI component by slug (optionally a specific version).

Get a documentation page by ID (includes Tiptap body, SEO, status, full_path, preview_url). IMPORTANT — `doc_id` MUST be a UUID, not a slug or full_path. Passing a non-UUID returns 404 (not 500). To look up by title/path, call content_list_docs (flat) or content_docs_tree (hierarchy) and filter client-side, then pass the matching `id` here.

Fetch a single curated background video by slug. Public read.

Get navigation menu (header, footer, docs_sidebar).

Get a content page by ID (includes blocks, SEO, status). IMPORTANT — `page_id` MUST be a UUID, not a slug. Passing a slug returns 404 (not 500 — task `3daae81c` fixed the previous unhandled-ValueError crash). To look up by slug, call `content_list_pages` and filter the response client-side (`pages.filter(p => p.slug === 'my-slug')`), then pass the matching `page.id` here. P5: pass `audit_level` to surface a `_page_audit` block — "warnings" (default) returns errors + warnings from the PageAuditor walk so the agent learns about scroll-sequence empty frames, missing primary domains, latent Tier 3 components, etc. without a separate content_export_page call. Pass "off" to skip the auditor.