Article destinations

Kitecraft keeps the article, independent review and exact destination package together. Choose one destination per project and reuse its saved settings. The owner approves the exact package before a CMS write or editor action. Writing works without a publishing connection.

The destination determines what can be automated: a compatible custom JSON API or the self-hosted WordPress preset can support native delivery and authenticated readback. Squarespace uses an editor handoff. A saved connection, successful preview or working read route does not prove a write. Reusable mapping and preparation controls may be newer than your connected deployment; check destination_status and fresh tool discovery before following that path.

Start with the destination you already use

• Custom API: select its documented write operation, JSON Schema and readback fields. Your agent prepares the contract, including your customer-specific localized content model. The owner saves the API origin and credential in Connections → Article destination.
• Self-hosted WordPress: use a revocable Application Password over HTTPS. The preset creates and reads back an unpublished post, or directly creates a brand-new published article after explicit approval of that publication package. An article that already has a CMS draft must be published from the WordPress editor. Core WordPress has no documented atomic revision contract for these writes, so automatic publication or live updates require an existing API with verified atomic revision support, or use the editor.
• WordPress.com: select the agent connection, including on the free plan. Your agent connects to WordPress.com's official OAuth MCP, uploads files directly to its media library, saves a draft and reads it back. Kitecraft prepares and retains the reviewed package; the customer's agent performs the provider operations. See WordPress.com setup.
• Wix Blog: use the official customer-agent MCP connection, exact site ID and a reviewed private-draft package. See Wix setup.
• Squarespace: use the saved article and metadata in the editor. Its documented public APIs do not establish blog/page publication. Kitecraft does not request a Commerce key for that job or call private editor endpoints. An existing supported JSON API can use Custom API.

The self-hosted Application Password preset and the WordPress.com agent connection use different authentication. No CMS write is included in a writing schedule by default.

WordPress.com setup

In Connections → Article destination, select WordPress.com (agent connection) and save your website origin. No WordPress password or token is entered in Kitecraft. Connect the same agent to both Kitecraft and WordPress.com. Preparing a package does not create a provider draft or prove the agent connection works.

WordPress.com's official MCP supports free and paid sites. Its endpoint is:

https://public-api.wordpress.com/wpcom/v2/mcp/v1

For Codex, use the official setup commands and complete WordPress's browser authorization:

codex mcp add wordpress-com --url https://public-api.wordpress.com/wpcom/v2/mcp/v1
codex mcp login wordpress-com

For Claude Code:

claude mcp add --transport http wordpress-com https://public-api.wordpress.com/wpcom/v2/mcp/v1

Then use Claude Code's /mcp command to authorize. ChatGPT users can use the WordPress.com connection instructions, subject to their host's connector availability. Other clients follow the official MCP connection guide. A connected server is only setup evidence: confirm that the intended site appears in wpcom-user-sites before doing any work.

WordPress defaults may expose reads while disabling writes. In AI and MCP → Write, enable only the capabilities needed: Create post, Update post, Upload Media, and Update media item. These are account-wide settings shared by connected clients, and post-write permissions also technically permit publication. Leave deletion, image generation, site administration and unrelated tools disabled. A draft-only instruction is an agent boundary, not a WordPress permission scope.

Prepare, save and verify a draft

Use destination_status, follow its project-specific setup, then call the shared destination_prepare operation. HTTP, MCP and CLI use the same content contract:

Use action: "draft". For a new draft use targetId: null and expectedRevision: null. To edit an existing draft, supply its ID and the exact last-read modified value together. The agent must reread it and stop if its content, revision or Draft status changed. WordPress's ordinary update is not an atomic compare-and-swap operation. Keep the edit bounded and stop for reconciliation when another editor changed the post.

After independent package review and the owner's authorization, the agent:

1. Confirms the intended site and numeric site ID with wpcom-user-sites.
2. Calls wpcom-mcp-content-authoring with action: "describe" for the needed operations. The live schemas are authoritative, including whether title/content/caption use a raw object.
3. Uploads any accessible local, generated or chat-attached files directly using WordPress's authorized media tooling. It uses media.create or the documented direct-upload flow, then retains the returned CMS IDs and URLs. Keep base64 bytes out of model context and Kitecraft packages. If the chat host cannot read the file, the owner uploads it in WordPress and supplies its CMS reference.
4. Calls posts.create or posts.update with explicit status: "draft", the reviewed fields and user_confirmed: true only when actual authorization exists. Reuse an existing draft instead of creating another. Omit featured_media when no featured-image change was requested.
5. Reads the same post using posts.get with context: "edit" and a bounded include_fields selection. Compare title, content, excerpt, slug, Draft status and featured media. Inspect _content_warnings: stripped or transformed content requires reconciliation before claiming exact delivery.
6. Reads affected media with media.get and checks URLs, alt_text and captions. Saves the observed provider result with artifact_save kind: "metadata", keeping the reviewed draft and progress intact. Use calendar_report action: "retain" only to attach exact existing draft, review or commission copies; it does not attach provider observations. Provider observations remain customer-agent evidence, separate from Kitecraft's native API-delivery receipts.

For an unknown write outcome, find and read the original target before retrying. A repeated posts.create can create a duplicate. Do not publish, launch the site or generate paid images as part of draft preparation. destination_send, destination_read and destination_reconcile are for native API destinations; use the authorized WordPress tools for this agent connection.

WordPress.com images and preservation

Featured images and inline images are separate. Upload both directly to WordPress. Set a featured attachment using featuredMediaId; embed inline CMS URLs with img alt text and a figcaption in the reviewed bodyHtml. Store accessible CMS references and the shared image metadata, not local paths or expiring attachment links.

Media-library alt_text and captions do not automatically replace values already embedded in static post HTML. When changing inline metadata, update the approved block markup as well and read both back. During a text-only edit, preserve the existing image block bytes, order and featured ID. Omitted image fields mean preserve, not clear.

The free-site pilot exercised direct upload, featured/inline images, alt/caption updates, draft creation, text edits and authenticated readback through the official WordPress.com MCP. That provider proof does not mean Kitecraft hosts a WordPress.com OAuth worker or performs these writes itself. Publication remains a separate owner decision.

Wix Blog setup

Select Wix Blog (agent connection) in Connections → Article destination. Copy the exact site ID after /dashboard/ in your Wix dashboard URL. An unpublished site is supported. Kitecraft stores this ID and the reviewed package, never your Wix login or token.

Connect the customer agent to the official Wix MCP at https://mcp.wix.com/mcp. Claude also offers Wix as a built-in connector. Its Wix consent grants account-wide editing and publishing capabilities, rather than a private-draft-only permission. Review that grant before connecting. Sites created through the connector can be published automatically, so use the existing selected site and do not create a site during this workflow. Availability in other chat hosts depends on that host. Confirm the exact site with ListWixSites and GetSiteContext, and install Wix Blog on it. A connection or package preview proves no provider write.

Read destination_status and use destination_prepare with action: "draft", the current connectionRevision, and content containing title, bodyMarkdown and slug. Optional fields are excerpt, seoTitle, seoDescription, memberId and shared images metadata. See the complete input example. New drafts use null target and revision. Existing drafts require the exact target ID and last-read editedDate together.

The agent must discover the current Wix schemas before provider calls. It converts Markdown to Wix Ricos rich content and maps slug to seoSlug. The complete converted request needs independent review against the retained article before owner authorization. Preparation validates the article package, not the Ricos conversion. Resolve an actual site-member author when required; do not invent a member or substitute a collaborator/contact ID.

Create at most one draft with the documented Create Draft Post operation and explicit publish: false. Never reuse a publishing example unchanged. Check for a matching existing draft before creation, and reconcile an unknown result instead of repeating the create. Do not publish the site, schedule the article or revert a published post.

For an existing draft, read the same site and target with RICH_CONTENT and complete metadata. Compare editedDate, content, schedule and publication history against the retained baseline before a bounded update. Wix edits are not claimed to provide atomic compare-and-swap. Concurrent changes stop the edit; preserve unmentioned rich-content nodes, cover image and metadata.

Upload approved images directly through the customer's authorized Wix media tooling. Use returned media IDs, dimensions, alt text, captions and placement. Read back the exact draft with rich content and metadata, compare all reviewed fields and images, and confirm no schedule or published counterpart/publication date. UNPUBLISHED alone does not establish a private draft when a creation request may have used publish: true.

Retain the exact native request and observed response with artifact_save kind: "metadata". These are customer-agent observations, not Kitecraft native delivery receipts. destination_send, destination_read and destination_reconcile do not operate Wix. No paid image generation, recurring collection or publication follows from this setup.

The self-hosted WordPress preset is authoritative when saved. Use Custom API for a different field mapping or API contract; importing a WordPress configuration does not override the preset.

Custom API setup

Each project has its own selected destination contract. Your agent does the API discovery and payload preparation; Kitecraft does not require your API to use our example's field names. A request may use your nested objects, localized fields, collection IDs or other JSON fields when its selected schema allows them. For example, your API's headline can be the article title and copy its body. The readback mapping makes those relationships explicit.

Start with project_context, then destination_status for the intended project. Its setup includes the owner setup URL, this guide, the authoritative OpenAPI schema and a complete downloadable example. The example is a draft-only illustration, not a preconfigured service. Your agent must replace its endpoints, schema and mappings with your API's documented contract.

Give your agent this task:

Set up this project's custom article destination. Read destination_status and its
setup guide/example. Inspect my authorized API docs or repository. Identify the
site, content model, draft-create operation, authenticated read-by-ID operation,
authentication header, state, revision and exact body/metadata fields.
Prepare non-secret DestinationConfig JSON using those actual operations, a
JSON Schema for the exact request body, and reusable request/expected mappings. Keep publish/update null until their
required semantics are supported. Explain unsupported capabilities.
Give me the project-specific owner setup link and the prepared JSON. I will
enter the credential there. Do not put credentials in chat, files or artifacts.
After read verification, prepare one private-draft package from the existing
reviewed article. Obtain its required package approval, send once and read back
the returned ID and complete mapped fields. Stop before publishing.

1. The agent inspects your API documentation or authorized source. TypeScript types or OpenAPI can help it prepare the selected JSON Schema. Kitecraft never runs uploaded TypeScript.
2. The agent gives you the complete configuration JSON and explains what can be read, drafted, updated or published. Unsupported operations remain null. Arbitrary JSON payload fields come from your API, not from a fixed Kitecraft article schema.
3. Open the setup.ownerUrl returned for your project. Select Custom API, then import the non-secret JSON under Advanced. Choose Bearer token, API key header or Username and password and enter the token or password in the masked form. Kitecraft constructs the header; do not add Bearer to a token-only input. The agent does not need to see the credential. Save, then choose Verify read access. This is one authorized read, not a test write.
4. The agent prepares the exact draft payload and expected readback values, saves the delivery artifact, and records validation and independent package review. You approve the exact package before a write, including a private draft.
5. Send once, retain the returned target ID and retrieve the exact body/state through destination_read. If a response is lost, reconcile; do not change request IDs to try again. Leave publication unavailable until that separate operation is supported and approved.

The matching content example supplies title, bodyMarkdown, slug and locale. Replace its sample article and connectionRevision with your actual reviewed content and saved revision. The retained mapping turns those fields into headline, copy, slug and language, then checks the same four values on readback. No secret belongs in either example.

The example's write returns {"created":{"id":"article-123"}}. Its authenticated read returns an article object containing id, state:"draft", a revision string, its canonical url, publishedAt:null, and the exact headline, copy, slug and language. Your API may use entirely different names and envelopes; update the pointers accordingly. A successful write response without complete readable content is insufficient delivery proof.

APIs with different protocols

The native adapter supports project-selected JSON bodies over fixed public HTTPS operations. It does not forward cookies, execute scripts, expose internal networks, or automatically translate arbitrary multi-step protocols. If your API requires multipart media, a signed request, several dependent calls or an unsupported concurrency mechanism, your customer agent can use its own authorized API tooling and retain a customer_agent_reported receipt. Report the unsupported capability so Kitecraft can add support; customers do not need to change their codebases. The constraint is the transport and verification capability, not your article field names. Do not silently weaken the API's validation or revision checks to fit an example.

Select a custom contract

Ask your agent to inspect your authorized API documentation or selected OpenAPI operation and prepare a DestinationConfig. The authoritative fields and constraints are in /api/v1/openapi.json, under the destinations operations. Import the selected request-body JSON Schema, rather than an entire service specification. Resolve external definitions into bounded local $defs first.

Configuration includes:

• One public HTTPS origin, fixed API paths and the supported draft/publish/update methods.
• An authorized probe path and a read path containing {id}.
• JSON pointers for ID, revision, status, canonical URL and an explicit-timezone publication timestamp. responseIdPointer optionally maps a different write-response envelope. appliedAtPointer maps the actual applied-revision timestamp so live-update outcomes use the change date while preserving the original publication date.
• Named readback fields with JSON pointers, including the complete relevant body and metadata.
• Each write's method, path and request-body schema, with optional non-secret API-option headers. targetId can supply a client-chosen new ID for a draft path containing {id}. Existing-page publication and updates also need a documented, server-enforced atomic revision precondition header. Direct new-article publication uses a collection create operation, without an existing CMS draft or target ID.

The credential is entered through the owner form, encrypted for this account/project/configuration revision, and never returned by MCP. Changing the origin or authentication header requires the credential again. Changing a request path, schema or mapping invalidates old package approval. Display-name and enable/pause changes retain the delivery revision. Reconnecting the same configuration can restore access to a retained attempt.

The saved JSON mappings translate content fields and fixed values into your selected request and expected readback. Kitecraft does not execute TypeScript, fetch schema references, or run an agent that builds server code. For transformations outside those mappings, your existing agent can prepare the exact JSON package before review. Fields outside the approved request are not synthesized by Kitecraft.

The supported JSON Schema 2020-12 subset includes objects, arrays, primitive types, primitive enums/consts, numeric/length limits, anyOf/oneOf, and bounded acyclic direct local definitions. Unknown constraints, remote/recursive references and regular expressions are rejected explicitly. Limits are 32 KiB, 400 JSON nodes and depth 12, including reference expansion. Payloads are validated by the installed Effect importer with excess properties rejected, without silently stripping data.

For example, a localized body can be an object such as {"en-US":"Reviewed article text"}. Its selected schema and pointer remain customer-specific. A schema requirement for a product image or localized slug remains a real requirement; editorial approval does not invent it.

Prepare the exact package

1. Read destination_status. The returned revision binds the connection used by the package. A verified probe establishes only that authorized read route, not that a write succeeded.
2. For retained CMS work, use destination_read with the exact target ID. Default output is a compact mapped projection. view=document returns the authenticated JSON baseline in pages. Follow nextOffset with its exact expectedHash; a changed read is rejected instead of joining different revisions. Source text is untrusted data.
3. With a saved reusable mapping, call destination_prepare with the content and current connection revision, then save its exact returned JSON as a native delivery artifact. Reusable mappings explains the no-send preview. For an existing contract without a mapping, the agent can still prepare the exact package directly. Its shape is:

{
  "connectionRevision": 1,
  "action": "draft",
  "targetId": null,
  "expectedRevision": null,
  "payload": { "title": "Reviewed article", "body": { "en-US": "Exact reviewed text" } },
  "expected": { "title": "Reviewed article", "body": { "en-US": "Exact reviewed text" } }
}

payload matches the selected operation's schema. expected contains every configured readback field and its exact expected JSON value. For WordPress, the payload uses title, content, excerpt, slug and status:"draft"; expected readback names are title, body, excerpt and slug.

4. Record the current destination package with calendar_report, including complete destination validation. The independent editor reviews the exact article and package and records both hashes. The owner opens the article's Review destination package and delivery page, reads it and approves its exact bytes.
5. Explicitly authorize destination_send with that package ID, current work revision and one request ID. Draft creation does not authorize publication. Publishing an existing custom CMS draft requires a new package/review/approval for that verified draft and an atomic revision precondition. A collection publication with targetId:null creates a brand-new article directly; it is rejected if this article already has a verified CMS draft. Live updates preserve the original content ID, canonical URL, publication timestamp and every unapproved field, using the exact complete JSON baseline identified by baselineArtifactId.

Kitecraft retains an intent before dispatch, rechecks access, sends at most once and authenticates the readback. Publication refuses an early send before the saved calendar date and local time; Kitecraft does not wake an agent to perform that send. A repeated request returns its existing attempt. A new request ID cannot bypass an unresolved attempt or create another draft for the same article. Native receipts say kitecraft_readback; manual customer-agent receipts remain customer_agent_reported.

Interrupted delivery

A timeout or uncertain response stays unknown, with the reviewed article and package retained. It does not buy research, evaluation or another API attempt. destination_reconcile reads the exact target and checks its approved fields/state. If creation lost its response ID, the owner must identify and confirm the exact CMS target before reconciliation.

A failed HTTP response or empty search is not proof that no write happened. If the CMS owner obtains authoritative evidence that an unresolved request did not apply and cannot apply later, retain that evidence as a metadata artifact. The owner-only resolve API records a no-application attestation tied to that artifact. This is explicitly owner-attested, not independent verification. It preserves the original attempt in history and permits a new deliberate request after current review and approval. Never use this to dismiss an in-flight write.

Native transport uses public HTTPS, rejects private/reserved DNS answers, pins the TLS request to the validated address, follows no redirects and bounds response size/time. Only configured paths are callable. No browser cookies or arbitrary outbound URL forwarding is supported.

Provider references: WordPress posts API, WordPress Application Passwords, Squarespace public API catalog.

API compatibility is explicit

The first custom transport supports one HTTPS origin and authentication header, fixed paths, a JSON request body, a JSON read document, direct ID/revision/state mappings, and optional atomic revision headers. The selected payload schema can describe nested and localized models. That flexibility does not establish a provider's publication protocol.

Contentful and Sanity have their own version, draft and publication semantics. An API requiring body-based conditions, a different publication identity, derived state, multiple origins or a multi-step transaction uses the agent's authorized native CMS tooling with a customer-agent receipt until Kitecraft supports that contract. Customers do not need to change their products to fit Kitecraft. Those provider-specific behaviors are not advertised as tested native connectors. This preserves one simple maintained contract instead of executing uploaded adapters or pretending every CMS has the same API.

Example: an existing API with client-chosen IDs

Download the DiveJourney configuration. It uses the site's existing authenticated GET /agent/posts?limit=1, PUT /agent/posts/{id} and GET /agent/posts/{id} routes. No customer code changes, collection bridge or Kitecraft-specific endpoint are required.

For the delivery package, set action:"draft", targetId:"your-new-article-slug", expectedRevision:null and payload to the API's own article object. The slug goes in the URL, not an invented envelope in the body. Kitecraft substitutes the ID as one encoded path value. The configured write sends If-None-Match: *, which this existing API enforces to reject an existing slug. PUT/PATCH draft creation is rejected without that create-only precondition; do not claim it works unless the API actually enforces it. Collection-style POST creation continues to use targetId:null and the returned ID.

The selected body schema requires draft status and a null publication date, plus the site's title, Markdown, excerpt, SEO and relation fields. The worker prepares these values against the existing API contract before independent review. Kitecraft sends the exact approved JSON. If the CMS trims metadata or changes ordering, compare its actual saved values rather than silently accepting a change. The bounded schema describes the selected shape; the CMS still validates its complete domain rules.

The write response identifies the target at /slug; readback identifies it at /item/slug. Status is /item/status, revision /etag, and the canonical future URL /public_url. Title/body/SEO mappings point into /item, while relation mappings point to the response's root arrays. Set expected to the exact submitted article object, with one entry for every configured field. Different response envelopes do not require server code or a universal article model. Routine destination_read uses the selected projection; a full document can include private preview capabilities and must remain private.

This example has no publication or update operation. A canonical future URL does not mean the draft is public. A lost response keeps the known slug and original attempt for read-only reconciliation, without another PUT. The owner enters their existing Bearer credential only in the encrypted owner form, never in configuration, prompts, artifacts or chat.

Squarespace private-draft onboarding

Choose Squarespace on Article destination, enter the site URL and save editor handoff. No Commerce API key is requested. The selection retains where the article will go; it does not establish API access, authorize browser access or create a post.

Prepare the editor handoff

An agent can use destination_prepare with the current connection revision, action:"draft", targetId:null, expectedRevision:null and these content fields:

• Required: title, bodyMarkdown and slug.
• Optional: seoTitle, seoDescription, excerpt, tags, categories and image metadata. Tags and categories are arrays of nonempty strings.

Use the complete Squarespace preparation input, replacing its sample article and revision. Do not pass HTML or additional fields; unsupported keys are rejected. This new-post handoff has no baselineArtifactId. Existing-post updates belong in the existing authorized editor record, preserving its identity rather than creating a duplicate.

The returned delivery package contains payload.kind:"squarespace_editor_handoff", the saved siteOrigin, saveAs:"draft", exact content, editor steps and limitations. Its expected object describes intended values, not observed readback. Preparation creates no Squarespace post. Retain the exact JSON as a delivery artifact, record its validation and independent review through the article workflow, and obtain owner approval before editing the site. Keep the original reviewed article and metadata available as well.

Save and verify a private draft

Your agent needs separately authorized browser access to that site's Squarespace editor, or the owner can complete the steps. Use a private trial site first when testing. No native destination_send, destination_read or destination_reconcile operation exists for this editor handoff.

1. Retrieve the exact saved article and approved handoff. Preserve the original files and review. Resolve substantive changes separately; inaccessible files do not authorize a replacement article.
2. Open the selected blog collection and create a new post. Enter its title and add the canonical Markdown through a Markdown block. Inspect the rendered result. Squarespace does not support every Markdown extension, and a rendered view does not establish identical stored Markdown bytes.
3. Set the post URL slug, excerpt, SEO title and description, tags and categories where supplied and supported by the editor. Verify each field rather than assuming it was imported with the body.
4. Explicitly keep Draft status and save. Do not select Publish or Schedule. Close the editor, reopen the same post and inspect the saved title, body, links, slug, metadata and Draft status. A future public URL or editor preview is not publication.
5. Retain the editor target, observed saved status, exact source artifact hashes and a field-by-field verification note. Report formatting differences or missing fields. This is customer-agent editor verification, not native kitecraft_readback proof. Report CMS completion only when its actual required evidence exists.
6. Keep the article awaiting its next authorized step. Publication and scheduling need their own owner decision; a private draft creates no live reader outcome.

The official Squarespace API inventory and Commerce API catalog do not establish blog-post writes. This path uses the ordinary editor, not Commerce keys, private endpoints or stored browser cookies. Squarespace's current MCP server provides domain tools, not a blog-post writing connector. Its content import is a separate source-platform migration path, not recurring article delivery.

Preparing a handoff is locally implemented behavior. A successful Squarespace private-draft save and reopen must be verified on the actual authorized site before it is claimed as complete. Kitecraft can support a future official content API after its contract is verified.

Squarespace images

Upload accessible local or generated files directly in the authorized Squarespace editor or Asset Library. Use the permanent CMS URL in the existing Markdown as ![alt text](cmsUrl), with a caption paragraph below, or reuse a native Image block. Use Content settings for the featured image. That setting did not expose separate featured alt-text or caption controls in the tested trial; retain the requested metadata and report this limit honestly. See Images and media for the shared metadata shape and host limitations.

Reusable mappings

Choose one destination in Connections → Article destination. Only the selected destination is shown. Manage connection lets you pause delivery, enable individual actions, replace a credential, or change the destination. Pausing retains the mapping and articles. Reads and reconciliation remain available while delivery is paused.

For Custom API, your agent prepares the connection from your existing API documentation. Import its non-secret contract under Advanced, or edit the paths and mapping rows. No customer code changes are required. Request methods are independent of content actions: an update can use POST, PUT or PATCH if that is your API's documented behavior.

Each action can retain a mapping with request and expected rows:

{
  "request": [
    { "to": "/article/title", "from": "/title" },
    { "to": "/article/body_md", "from": "/bodyMarkdown" },
    { "to": "/article/status", "value": "draft" }
  ],
  "expected": [
    { "to": "/title", "from": "/title" },
    { "to": "/body", "from": "/bodyMarkdown" }
  ]
}

from reads a JSON pointer in the supplied content. to sets a JSON pointer in the request or expected-result object. Fixed value rows support JSON strings, numbers, booleans, null, objects and arrays. Map complete arrays or objects in one row. Paths cannot overlap or use prototype keys. No expressions, scripts or uploaded code execute.

A missing source field fails preparation. With optional: true, a missing field is omitted; explicit null is still sent. Use null only when the API documents it as clearing a nullable value. An update expecting a complete replacement must receive the complete preserved record. A partial update can omit unchanged request fields, but its expected-result mapping must still describe every configured readback field after the update. Existing baseline and atomic revision checks remain required.

Prepare content through any interface

The same operation is exposed as MCP destination_prepare, HTTP POST /api/v1/destinations/{projectId}/prepare, and CLI kitecraft destination prepare --id PROJECT_ID --json JSON.

{
  "connectionRevision": 2,
  "action": "draft",
  "targetId": "my-new-article",
  "expectedRevision": null,
  "content": {
    "title": "My new article",
    "bodyMarkdown": "# My new article\n\nThe exact reviewed text.\n"
  }
}

For a custom API or WordPress, the result is an exact native delivery package containing the transformed payload, complete expected readback values, action, target and configuration revision. Preparation performs no CMS request, saves no artifact and grants no approval. Retain this package as a delivery artifact, independently review it and obtain owner approval before destination_send. A changed mapping creates a new connection revision and requires a new package and approval. Existing exact packages without mappings continue to work under their original contracts.

Routine destination_status reads return a compact summary with enabled actions and source content paths. Request view: "contract" (HTTP query view=contract, CLI --view contract) explicitly for configuration or debugging. Owner connection pages use the full saved contract. No status view returns credentials.

Preview a request uses the current unsaved editor settings locally. It never calls the CMS and does not replace server validation. A successful preview proves transformation and request-schema compatibility, not API access or successful delivery.

Content and structured data

Content keys are project-specific, not a compulsory universal CMS model. Typical inputs include title, Markdown or prepared HTML, excerpt, slug, locale, SEO title/description, author, tags, media references, related entities and structured data accepted by the destination. Your agent supplies these values; Kitecraft does not invent missing fields. WordPress's built-in mapping uses title, bodyHtml, excerptHtml and slug. HTML conversion belongs to the writer; no hidden Markdown conversion is performed.

Revise a private draft through a custom API

Use the existing update operation with publicationState: "draft", the exact targetId and expectedRevision, and baselineArtifactId pointing to the complete authenticated JSON baseline retained as the current source. Report that source as private, ready and complete, preserving its original identity and null publication date. The selected API must enforce an atomic revision precondition. Existing update packages without publicationState retain published-page semantics.

Prepare the corrected article and complete expected readback, save the exact package, obtain a fresh independent review and explicit owner approval, then send once. The Delivery screen says Update private draft. This can happen before the calendar publication date. Kitecraft compares the complete baseline before the request, checks all untouched fields and the same identity/publication state afterward, and requires a new CMS revision. A verified private revision stays unpublished and creates no publication receipt.

If the response is lost or readback differs, preserve the attempt and use destination_reconcile on that exact target. Do not create another draft or resend under a new request ID. Publication always requires a separately reviewed and owner-approved package. Unsupported provider operations remain unavailable.

The DiveJourney example maps bodyMarkdown to body_md and fixes draft status and a null publication date. It uses the unchanged existing API with a create-only PUT and authenticated readback. Publication and updates are disabled in that example.

A static-site API can accept JSON such as { "path": "articles/example.md", "content": "Markdown text" } through a saved mapping. The API must provide the identity, status, revision and content readback used by this connector. A Git-only site needs the customer's authorized repository workflow. Raw Markdown transport, multipart uploads, arbitrary code, OAuth refresh and multi-request API workflows are not supported by this JSON connector.

Credential handling

Select Bearer token, API key header or Username and password. Enter the token or password only; Kitecraft constructs the authentication header. A saved connection offers Keep saved credential and never displays the original secret. Replacing a secret requires selecting its authentication method. Changing the origin or authentication header requires supplying the credential again.

Credentials are encrypted using authenticated AES-256-GCM with an independent server key and account/project/revision binding. They are decrypted only for authorized server requests, never returned through tools, embedded in contracts or saved in content artifacts. Only the owner browser session may change configuration and credentials. The destination table denies browser-role access and enables RLS; server operations also authorize each project independently. Encryption does not replace revocation or limited provider permissions. Use revocable credentials with the smallest necessary scope, and rotate/revoke them at the provider when needed. Disconnect removes Kitecraft's stored credential; it does not revoke the provider's token.

The transport restricts requests to the approved public HTTPS origin, rejects private network destinations and redirects, and keeps request credentials out of diagnostic responses. Approval, revision preconditions, exact readback and uncertain-outcome reconciliation remain in force. The credential never belongs in the downloaded configuration or a content example.

Images and media

The CMS owns the image files. Kitecraft stores the article's CMS media references and editorial metadata in its existing reviewed package and saved artifacts. It does not host a second image library or require a Supabase upload. A local or generated file goes directly from your agent to your CMS using that destination's authorized media API or normal editor.

1. Give your agent the local file or generated/chat attachment. It must actually be able to download or open those bytes; a path on another machine or an inaccessible chat attachment is not a transferable image.
2. Upload once through the CMS's supported media route or editor. If your chat host cannot transfer attachments or use the CMS, ask the owner to upload there and return its CMS media ID or permanent URL. Never claim an inaccessible attachment was uploaded.
3. Include permanent inline image URLs, alt text and captions in the article body before freezing the reviewed package, then retain the returned CMS reference, chosen placement, alt text and caption with the article package. Use the CMS-owned URL or media ID in the article payload. Do not embed a local path, base64 binary, an expiring chat download link or an API credential.
4. Reopen or read back the post and verify its actual image source, visible caption, informative alt text and featured image. An accepted upload response alone does not prove those fields appear on the page.

For Squarespace, destination_prepare.content.images accepts up to20 entries:

{
  "sourceRef": "https://images.squarespace-cdn.com/content/your-site/photo.png",
  "placement": "inline",
  "altText": "A shop owner recording a customer inquiry",
  "caption": "A small inquiry log makes the next decision clearer.",
  "decorative": false,
  "afterHeading": "Keep a small working packet"
}

sourceRef is a bounded nonblank CMS media reference, not a request for Kitecraft to fetch a URL. placement is inline or featured; afterHeading is a heading or null, and must be null for a featured image. Only one featured image is allowed. Informative images require meaningful alt text; decorative images require decorative:true and empty alt text. Captions may be empty. The package freezes these requested values for review and does not claim they have already been saved in the CMS.

Before a text edit, record existing image URLs or IDs, native block IDs, order, alt text, captions and the featured image. Change the existing text blocks in place; preserve all unmentioned images and their metadata. Omit image fields when no image change is intended. Explicit image replacement or removal needs the owner's approved change. Reopen and compare afterward. Squarespace observations remain customer-agent evidence, not a native blog API receipt. Do not change a published post's state while working on a draft package.

For self-hosted WordPress, the agent can use authorized POST /wp-json/wp/v2/media for binary upload, then update that media's alt_text and caption. Pass the resulting numeric featuredMediaId in destination_prepare.content to map it to featured_media. Use the returned CMS URL in bodyHtml for inline images. Omission of featuredMediaId leaves that field out of the request. An older saved WordPress mapping must be saved again in Connections before it can accept the new featured-image field; preparation explains that repair rather than silently omitting the image. Media can be publicly accessible even when a post is a draft, so obtain appropriate consent before uploading a private or sensitive photo. The tested WordPress6.8.3 installation verified native REST upload, metadata and image preservation; Kitecraft's shared adapter verified draft create/readback. Automated updates to existing core WordPress posts remain disabled without the required atomic revision precondition.

Custom API mappings can pass whatever CMS image URL, ID or nested metadata the selected schema supports. Binary/multipart upload stays with the customer's authorized tooling; the JSON adapter does not pretend to implement an unknown upload protocol. The agent documents that CMS's actual upload operation and maps its result into the existing article contract. No customer code change is required.

These transfers do not require a brief, evaluation or image-generation call. Your CMS's storage, privacy and bandwidth rules apply. If a future workflow needs durable pre-CMS media staging, that is an optional product decision, not a requirement of this flow.