ai.spideriq/publish

Fetch a single page template by slug. Public read — no auth required. Returns the full detail including the ONE source page that gets cloned on apply, its components, and any settings keys. Use this to preview a template before calling content_apply_page_template. (A page template is a content_site_templates row, so this resolves the same endpoint as content_get_site_template.)

Fetch a single page version snapshot in full (includes the historical `blocks` body). Use when you need to diff a candidate restore against the current page before calling content_restore_page_version.

Look up the canonical tool-sequence for a stated goal. No intent → returns the index of all available playbooks (task keys + when-to-use summaries). Intent = exact task key (e.g. "build_a_directory") → returns the full recipe. Intent = natural language (e.g. "build a directory") → fuzzy-matches against task keys + when-text, returns up to 3 best matches ranked by score. This is the fastest way for a fresh agent to find the right tool chain for a given goal without scanning the full /content/help (~50 KB). Each recipe names the exact tools to call, common variants, and anti-patterns.

Get a blog post by ID (includes body, tags, author, status).

Get the current Liquid source for a named section (header, footer, hero, etc.). Param-name compatibility (templates.ts duplicate merged here 2026-05-20): - Canonical: { section_slug } - Legacy: { section } When to use this instead of template_get: - You want to see "what Liquid is this client currently rendering for the header?" - You want to check whether an override exists for a section before writing one - You want to copy the current source as a starting point for modification Returns: - If client has an override: returns the override source with origin="client_override" - If client has no override: returns origin="theme_default" with instructions. The bundled theme default source itself lives in the public starter kit, not the API — see SpiderIQ/SpiderPublish repo.

Get your brand's content settings (site name, SEO defaults, analytics, colors).

Fetch a single site template by slug. Public read — no auth required. Returns the full template detail including the list of pages, components, nav locations, and settings keys that would be cloned on apply. Use this to preview the impact before calling content_apply_site_template.

**START HERE for personalized landing pages.** Returns the full merge-tag vocabulary ({{firstname}}, {{company_name}}, {{city}}, {{industry}}, {{logo}}, {{email}}, ~40 tokens total) for dynamic-landing templates — Mailchimp-style flat tags every LLM already knows. Includes plain-English descriptions, realistic example values from the Mario's Pizzeria demo fixture, and selection rules (e.g. how `{{ email }}` picks the best verified address). Works without auth. Fetch once at session start — you'll know every variable you can drop into a Liquid template.

Import a doc OR page from a Markdown body — the universal Markdown→content bridge. target='doc' parses Markdown into a Tiptap doc body; target='page' parses prose runs into rich_text blocks. `:::component{slug=… version=… props={…}}` directives become embedded components (the MDX unlock). Create a NEW item (omit the id, pass slug + title) or REPLACE an existing one's body/blocks (pass doc_id for a doc / page_id for a page). The Phase 11+12 gate is opt-in via dry_run/confirm_token and applies on the REPLACE path (omit both ⇒ immediate). Round-trips with content_export_markdown. Markdown is capped at 256 KB.

Generate a full API-reference docs section from ANY OpenAPI 3.x or Swagger 2.0 spec (the flagship 'docs as a product' feature — Stripe/ReadMe/Mintlify-tier). Provide EXACTLY ONE of source_url (fetched server-side, SSRF-safe) or spec_content (pasted JSON/YAML). Creates one doc page per tag under the `section` slug (default 'api-reference'), each endpoint with method/path/params/schemas and auto multi-language code samples (curl/Python/JS/Go) in a `:::codegroup` block. Re-import is IDEMPOTENT — the importer owns the section subtree (upserts tag pages, archives removed ones). Use dry_run=true to preview the planned section + pages without writing. Docs are created as drafts unless publish=true.

List your brand's blog authors.

List your brand's blog categories (supports hierarchy).

List available CDN libraries for component dependencies (Tier 3). Returns keys, names, URLs, categories. Use these keys in the dependencies array when creating/updating components.

List all versions of a component by slug.

List UI components (reusable blocks with Shadow DOM isolation).

List your brand's docs as a FLAT list (metadata only — no body). Complements content_docs_tree (which returns the hierarchy). Use this to discover a doc's UUID by title/status before fetching or mutating it via content_get_doc. Each item carries id, slug, full_path, title, status, parent_id, is_section, sort_order, seo_*, timestamps.

List custom domains configured for your brand's content site.

Browse the curated background-video library — 12 short looping clips across 6 categories. Public read, no auth. When to use: - Picking a clip for a hero-video-bg or sys-bg-video block - Surfacing the catalog on a dashboard "browse bg videos" page Categories: nature | city | abstract | food | tech | people Each result carries: slug, name, description, r2_url, poster_url, duration_seconds, loop_seconds, category, tags, is_featured.

Browse the SpiderIQ section library — ready-to-insert sections grouped by category. Public read, no auth. When to use: - Filling out an existing page that needs a hero / pricing / FAQ block - Adding a sign-in / forgot-password / reset-password page (category=authentication) - Picking the right component shape before calling page_insert_section - Surfacing the gallery on a dashboard "browse sections" page Categories (use `category` filter): hero, features, pricing, social-proof, content, forms, team, footer, header, cta, faq, authentication The `authentication` category holds 3 designable sign-in bricks (spideriq/auth-login, spideriq/auth-forgot-password, spideriq/auth-reset-password), each rendering a <spideriq-auth> custom element (CLOSED shadow DOM). Their props REQUIRE `auth_target` ("dashboard" = sign into the SpiderIQ dashboard; "site_members" = the tenant's own members). These are a designable shell + integration contract — the real auth backends are wired by Login Initiatives B/C; until then submit degrades gracefully. See the content/help `build_a_login_page` task recipe for the full flow. Each result carries: - slug + name + version (use slug + version for page_insert_section) - props_schema + default_props (validate before insert) - preview_thumbnail_url (designer-curated card art, R2) - marketplace_category + marketplace_featured + marketplace_description

List SpiderIQ-curated SINGLE-PAGE templates (the Page Template catalog). Public read — no auth required. When to use: - An agent or client needs a landing page, opt-in, thank-you, VSL, webinar, sales, coming-soon, 404, or pricing page and wants a proven starting point - ALWAYS prefer this over generating a page from scratch — clone-and-adapt is faster and more reliable than authoring Liquid blind ("adapt, don't generate") Each template carries: - slug (clone with content_apply_page_template) - name + description + industry + use_case + tags - preview_url (live preview) + preview_thumbnail_url (R2 screenshot) - source_page_slugs[] — exactly ONE page (that's what makes it a page template) - applied_count (popularity) This is the same catalog as content_list_site_templates, narrowed to is_single_page=true. Use content_list_site_templates for WHOLE-SITE starter kits (multi-page).

List version snapshots for a page (newest first). Each version is created on publish + on restore — use this as the canonical "history" before content_restore_page_version. Returns metadata only (block_count, blocks_size, change_summary, created_at, changed_by); the heavy `blocks` payload is fetched lazily via content_get_page_version.

List your brand's content pages (including drafts).

List your brand's blog posts.

List SpiderIQ-curated site templates. Public read — no auth required. When to use: - Client wants to see what starter sites are available before committing - Filtering for a specific industry (saas, agency, restaurant, ecommerce, portfolio, local-service, blog, event, landing) or use case (marketing, docs, blog, directory, personal) - Surfacing the featured set on a dashboard "browse templates" page Each template carries: - slug (apply with content_apply_site_template) - name + description + industry + use_case + tags - preview_url (live preview at preview-XXX.sites.spideriq.ai) - preview_thumbnail_url (R2-hosted hero screenshot) - source_page_slugs[] (which pages get cloned on apply) - applied_count (popularity)

List your brand's blog tags (includes post count).

Lock a content page against further edits. Use when handing the page off for client review or scheduled launch. Idempotent — re-locking refreshes the reason. Other agents and dashboard users will receive 423 Locked on every mutation until you (or a super_admin) call content_unlock_page.

Override a site section (header, footer, hero, sidebar, etc.) — or the blog listing / single-post templates — for this client. Param-name compatibility (the older templates.ts duplicate of this tool was merged here 2026-05-20 — both naming conventions work): - Canonical: { section_slug, liquid_source } - Legacy: { section, liquid } Pass either pair. If both are supplied, the canonical names win. When to use this instead of template_upsert: - You want to customize the header, footer, blog listing, or another named section just for this client - You have Liquid source and know the section slug - You don't want to touch layouts or individual page templates Section slugs are the filename (without .liquid) under themes/default/sections/ — the common ones are "header", "footer", "hero". The tool writes to sections/{slug}.liquid in the client's template override KV. Special slugs that target top-level templates instead of sections/: "blog-listing" → templates/blog.liquid (the /blog index) "blog-post" → templates/blog-post.liquid (single /blog/{slug} pages) "layout" → layout/theme.liquid (the outer HTML shell) "head" → snippets/head.liquid (the <head> contents) There is no "dm-blog-listing" or other branded blog component — the blog UI is template-based, not block-based. Use this tool (or template_upsert) to restyle it; do NOT try to PATCH a content_components row for the blog. Use content_get_section_source(slug) first if you want to see the current override or know whether one exists.

Publish a draft component (makes it available for use in page blocks). Phase 11+12: defaults to dry_run=true — review the preview and call again with confirm_token.

Publish a draft doc (status → published). Phase 11+12: defaults to dry_run=true — review the preview and call again with confirm_token to actually publish.

Publish a draft page (creates a version snapshot). Phase 11+12: defaults to dry_run=true — review the preview and call again with confirm_token to actually publish.

Publish a blog post.

Trigger a rebuild of a framework component (Tier 4). Returns 202 — poll with content_get_build_status.

Restore a page to a historical version snapshot. Phase 11+12 gated: defaults to dry_run=true — review the preview (which lists snapshot_block_count vs current_block_count + snapshot_created_at) and call again with confirm_token to actually restore. The restored page becomes draft; a new version row is appended recording the restore. Returns 423 Locked when the page is locked — pass force=true (super_admin / brand_admin only) to override.

Search published posts by keyword (public, no auth needed).

Set a verified domain as the primary domain for your content site.

Unlock a content page. Default: only the actor who originally locked it can unlock. Pass force=true (super_admin or brand_admin only) to override regardless of who holds the lock. Returns 403 with `not_lock_holder` if the caller is not the lock-holder and force is not set.

Revert a published doc to draft. Phase 11+12: defaults to dry_run=true — review the preview and call again with confirm_token to actually unpublish.

Revert a published page to draft. Phase 11+12: defaults to dry_run=true — review the preview and call again with confirm_token to actually unpublish.

Revert a published post to draft.

Update an author profile.

Update a blog category.

Update a UI component (template, CSS, JS, props schema, metadata). Use this to upgrade an existing component to a Phase A 4-class taxonomy entry — pass `kind` + (when kind != 'static') `js_runtime`. PATCH semantics: cross-field invariants (kind+block_type pairing for kind='dynamic', extension_spec required for kind='extension') are validated by the DB CHECK constraints in migration 174 — backend returns 400 with the constraint name if the patched row would violate them. Use the universal axes (mood / palette / brand_fit_tags / scene_type) to backfill agent-discovery metadata on rows authored before the marketplace search shipped.

Update a documentation page (title, body, SEO, hierarchy). Slug is immutable — to re-path a doc, change its `parent_id` (full_path is recomputed for the doc + its whole subtree). Moving a doc under one of its own descendants is rejected (cycle → 400). Phase 11+12 gate is opt-in via dry_run/confirm_token (omit both ⇒ immediate update).

Update navigation menu items.

Update a content page (title, blocks, SEO, template). Phase 11+12 Lock 4 gate is opt-in via dry_run/confirm_token.

Update a blog post (title, body, excerpt, tags, cover image, author, categories, featured, SEO).

Update post status (draft, published, archived).

Update content settings (site name, SEO, analytics code, primary color, custom head scripts, etc.). IMPORTANT: wrap the fields you want to change inside a top-level `settings` object — pass `{ settings: { site_name: 'X', primary_color: '#abc' } }`, NOT `{ site_name: 'X', primary_color: '#abc' }` and NOT `{ changes: { ... } }` (other tools like `form_update` use `changes:`; this tool uses `settings:`). The wrapper is required; calls without it return 422 'Field required'. Phase 11+12: defaults to dry_run=true — review the preview and call again with confirm_token to apply.

Patch an existing site-template catalog row (rename, attach a preview image, toggle is_public, retag, change source bindings, flip is_single_page). Phase 11+12 gated. AUTHORING-ONLY. Auth: same as content_create_site_template (super_admin OR marketplace-authoring-brand PAT). Commonly used right after content_create_site_template to set preview_thumbnail_url from a content_upload_template_preview result, or to publish a staged draft (is_public=true). Phase 11+12 flow: dry_run=true → confirm_token → call again with confirm_token. Only the fields you pass are changed.