Publish to your website

When your site runs on Payload CMS, Mark can send approved blog posts, FAQ pages, competitor pages, and landing pages to it. You review and approve them in Mark as you do social posts. Mark then saves each one in your CMS at its scheduled time, or within five minutes if it has none, and records the page's URL.

Payload is the only CMS Mark connects to today. Approve is blocked until that post type has a connected, mapped CMS.

Before you connect

In your Payload admin, you need:

• A user for Mark with API keys turned on. It needs to create and update posts and upload images. Updating also lets Mark unpublish a page when an admin deletes its post with Remove from Mark and take it down. To remove the page from your CMS entirely, and to clean up preview drafts, the user also needs to delete posts. Without that, those pages stay in your CMS as drafts and Mark tells you where.
• That user's API key. You paste it into Mark once. Mark encrypts it, never shows it again, and never gives it to an AI agent.
• Drafts enabled on the collection Mark publishes into (versions.drafts in Payload). Save a draft in Payload depends on this; without it Mark cannot keep an unpublished document in your CMS.

Connect Payload

1. Go to Presence > Channels. The Website group has a CMS row. Select Connect to open the connection form in a side sheet. Only workspace admins can change this connection. The same form is also on Settings > Connections > Payload CMS.
2. Enter your Payload site URL: the https address your Payload admin runs on, with no path.
3. Paste the API key. Leave API key collection as users unless your Payload keeps API users in another collection.
4. Under On approval, keep Save a draft in Payload. Switch to Publish live once the first post looks right in your CMS.
5. Select Test to check the connection before saving. Test keeps the key you pasted. It never creates a document.
6. Select Save connection. Mark reads your collections and fields. Key saved then appears next to the API key field, and the key field clears. Leave that field blank later to keep the stored key. Save with no key stored yet shows Enter the API key to connect.

To change the site URL or key collection later, enter the API key again.

Disconnect or revoke

To stop Mark publishing to your CMS:

1. In Payload, revoke or delete the API key (or the user) Mark uses.
2. In Mark, open Presence > Channels, select Manage on the connected CMS row (titled Payload CMS), then Disconnect. The same control is on Settings > Connections. Only workspace admins can disconnect.

Disconnecting deletes the stored key and mapping from Mark. Pages already in your CMS stay. Queued publishes fail until you connect again and map the post types. An AI agent with admin access can also call disconnect_connection.

Choose where new media goes

Mark reads images from every media collection in your CMS, except the one your API key's user belongs to. Pickers can browse under Media lists them. Social posts and body images can come from any of them; a cover comes from the collection your cover field accepts (see below). Mark never uploads a file from a picker.

New media goes to is the one collection Mark uploads into. When a website post publishes, Mark uploads its cover and body images from Mark's library there. Images you picked from your CMS stay where they are. Pick None: Mark uploads nothing to keep Mark out of your media library. Then covers and body images must come from your CMS, and Mark won't submit a website post that uses an image from Mark's library until you pick a collection or swap the image.

If your CMS's cover field accepts only one collection, Mark uploads covers there instead, and the post type shows Covers upload to with that collection. Mark can tell only when your CMS lets it read field details. If your CMS refuses a cover because its field takes another collection, the publish fails and names the field. Set New media goes to to that collection, or pick a cover from it.

Until you pick one, each post type keeps uploading to the media collection it used before, and a post type that sent no images still sends none. Pick a collection, or None, and select Save mapping to save it.

Choose where each post type goes

Under Where each post type goes:

1. Turn on a post type, such as Publish blog posts to this CMS.
2. Pick the Collection. Mark fills in the fields it recognizes. Check each one against your collection.
3. Pick the Body format. Choose Markdown when your collection has a markdown field. Otherwise choose Rich text, and Mark converts the post, tables included, into Payload's rich text.
4. Set the Live URL pattern, for example https://www.example.com/blog/{slug}. Mark records this URL on the post.
5. Optionally set the Draft preview URL: the address on your site that shows an unpublished draft. Use {slug}, or {id} for the document's id in your CMS, for example https://www.example.com/blog/preview/{id}?token=YOUR_PREVIEW_SECRET. Anyone in your workspace who opens the preview link sees that token, and AI agents connected to Mark can read it too. On many sites one preview token opens every draft, so use one that only shows drafts.
6. Add Fixed values for any required field Mark can't fill, such as an author id: { "authors": [1] }.
7. Select Save mapping. Mark refuses a collection or field your CMS doesn't have and names the one to fix. It also refuses the collection your API key's user belongs to, and your media collections.

If you add a collection in Payload, select Read collections again.

How rich text comes out

With Rich text, a link to another site opens in a new tab. Links to your own site stay in the same tab, and so do relative links like /blog/x, #anchor links, and email or phone links. Your own site is any site on Sites, plus the site in your Live URL pattern. A subdomain counts, so www.example.com and cms.example.com are both example.com.

A single line break inside a paragraph becomes a space, the same as the preview in Mark. For a new line, leave a blank line to start a new paragraph, or end the line with two spaces or a backslash.

Choose a cover image

The cover sits above the title, where your page shows it. In the post editor, select Add cover and pick or upload a PNG, JPEG, or WebP of 8 MB or less. Then describe the image in Cover alt text. Use Change to pick another image, or Remove to have no cover. A website post carries no other attachments: put images inside the article in the body.

A blog post needs a cover before you can submit it when Mark can publish one: its post type has a Media collection picked, and a cover or social image field mapped. With No images, or with no CMS for blog posts, the readiness checklist suggests a cover but doesn't block submit. FAQs, landing pages, and competitor pages need one only when your CMS requires it.

To use an image that's already in your CMS, select From your CMS next to Add cover. It lists images newest first, and you can search by file name or alt text. It lists the collection your cover field accepts, or the one new media goes to when Mark can't tell. Mark points the page at that image and uploads nothing, so your CMS doesn't get a second copy.

A cover from your CMS starts with the alt text your CMS has for it. If you change it in Mark, Mark updates that image's alt text in your CMS when the post is approved, which changes it on every page that uses the image. Sending a preview never changes it.

An AI agent sets the cover with save_post: meta.cover = { source: "asset", assetId, alt }, using an image id from search_assets or add_asset, or meta.cover = { source: "cms", mediaId, collection, alt }, using an image id and collection from search_cms_media called with the post's post type as channel.

Add an image from your CMS to the body

Put the cursor on an empty line in the body. A round image button shows at the left of the line. Select it to open From your CMS, pick a collection if there's more than one, pick an image, and select Insert. The image sits on its own line and starts with the alt text your CMS has for it.

With Rich text, approving the post points the page at that image in your CMS. Mark uploads nothing, so your CMS doesn't get a second copy, and your site shows the image's alt text from your CMS. If the image is deleted from your CMS, approve and Send preview fail with a message naming the file. Pick the image again from your CMS, or remove it from the body, then approve again.

With Markdown, the body keeps the image's address as it is, and Mark doesn't check that your CMS still has the file. Mark never changes the alt text of a body image in your CMS.

An AI agent does the same with search_cms_media, with any collection from get_website_cms: each result has a url. Put ![alt](url) on its own line in the body with save_post.

What a website post needs before review

Once its post type goes to your CMS, submit stops a website post until:

• the slug uses only lowercase letters, numbers, and hyphens
• the excerpt and meta description are 160 characters or fewer
• the cover image has alt text
• that cover is a PNG, JPEG, or WebP of 8 MB or less (not an SVG)
• a cover is set, on a blog post when Mark can publish its cover, and on any post when your collection requires one
• no other page in the mapped collection uses the slug (see When another page uses the slug)
• the Payload connection doesn't need attention

Without a CMS for that post type, the first three show in the editor's checklist as advice and don't block submit.

Review a website post

The review page shows the post as a page: the search result first, then the article with its cover, headings, lists, and tables. The Website panel names the collection, the page URL, and what happens on approval. Approve stays blocked until that post type has a mapped, working CMS. What we will send shows the exact document Mark sends.

Preview on your site before approval

A blog post, FAQ page, competitor page, or landing page can go to your CMS as a draft before anyone approves it, so the reviewer sees the real page on your site. Send preview is under Preview on your site at the top of the editor's settings column, and in the Website panel of the review page.

• It's there for a draft, a post with changes requested, or a post in review. After approval, approval owns the write. A refresh of a page that's already live isn't previewed; approving it updates the live page.
• It needs drafts on the mapped collection. Without them, anything Mark saves there goes live, so Mark refuses and says why.
• It always saves a draft, even when the connection is set to Publish live. Nothing goes live, and a page that's already live stays as it is.
• The editor saves your changes first, then sends what you saved. The post shows the preview link, when it was sent, and who sent it. If you edit the post after that, it says so. Send preview again updates the same draft.
• Approving updates that same draft, as a draft or published live per On approval. Mark never creates a second page for it.

The preview link opens only if you set a Draft preview URL and your site can show drafts. Whether a draft is hidden from public visitors depends on your collection's read access in Payload. Allow only _status: published for the public.

If someone publishes a preview in your CMS before it's approved in Mark, the daily check flags the post with a note. Mark doesn't mark it Published. If your CMS saves a preview live because the collection no longer has drafts, Mark tells you right away and flags the post.

If you reject, archive, or delete the post, Mark deletes its preview draft from your CMS, as long as its API key may delete drafts. Give the key's user delete access limited to documents in draft status (in Payload, a collection delete access that returns { _status: { equals: "draft" } } for that user). That lets Mark clean up and nothing else.

Mark leaves the draft alone when its key can't delete it, when someone edited it in your CMS after Mark sent it, when it's live, when it's a page you chose with Use this page (Mark didn't create it), or when your CMS doesn't answer. Then it tells you the draft is still there, with its preview link and the reason: in the post's review note when you reject or archive, and in the message you see when you delete. Delete it in your Payload admin.

When another page uses the slug

Before every send, the first preview, a resend, or an approval, Mark checks the mapped collection for other pages that use the post's slug. That covers a page's saved version and its latest draft. Mark never writes to a page that isn't this post's own, and it never changes the slug for you.

If another page uses the slug, Send preview shows that page instead of sending: its title, whether it's a draft or live, and Open in CMS to see it there. Then pick one:

• Use this page: make that page this post's page. Mark replaces its content with this post and keeps it a draft. Previews and approval update it from then on. It's offered only for a draft that no other Mark post uses.
• Change slug: give this post a different slug, then send the preview again. You can change the slug while the post is in review.

When the page belongs to another post in Mark, the panel links to that post. When the page is live, Mark won't replace it, because Mark didn't create it.

In Payload, renaming a draft doesn't free its old slug. Payload keeps the slug on the saved page until you publish or delete that page. The panel then shows the page's saved title, and the info icon shows the renamed draft's title, which is the one your Payload admin lists.

After approval

• Publish live: Mark publishes the page and marks the post Published with its URL.
• Save a draft in Payload: Mark saves a draft. Publish it in your Payload admin. Mark checks every 15 minutes and marks the post Published when the page is live.

Mark uploads the cover you chose and any Mark-hosted images in a rich-text body to the collection under New media goes to (covers go where your cover field requires, when Mark knows). The page's cover and social image fields point at that upload. If Mark cannot read the file, the post fails with the reason on the review page. Fix the file and select Retry.

A cover you picked from your CMS isn't uploaded: the page's cover and social image fields point at the image already there. If that image was deleted from your CMS before approval, the post fails and asks you to pick another.

An image you added to Mark from your CMS's own URL isn't uploaded again either. Mark matches it to the image already in that collection and points the page at that one. Mark changes that image's alt text only when the post publishes, never on a preview.

If a publish fails, the post shows Failed with the reason on its review page. Fix the cause, then select Retry.

A slug another page took after the post was submitted fails here too. The review page then shows that page, the same way Send preview does, with Use this page and Change slug instead of Retry:

• Use this page: Mark offers it only for a draft that no other Mark post uses. Mark asks you to confirm, makes that page this post's page, and sends the post again in one step. Mark replaces the page's content with this post. With Publish live, that publishes the page. With Save a draft in Payload, it stays a draft.
• Change slug: give the post a different slug, then approve it again.

A live page, or a page another Mark post uses, gets no Use this page. If the page changed between loading the review page and your confirm (it no longer uses the slug, went live, or another post took it), Mark refuses with the reason and writes nothing.

An AI agent does the same with sync_connections: pass the failed job's retryJobId and the page's CMS id as useCmsPageId. get_post returns the failed job id, and its reviewNote lists each page's CMS id.

If Payload refuses the API key, the connection shows Needs attention until you save a working key.

If someone edits the page in your CMS after Mark last sent it, Mark does not overwrite those edits when you approve again. The review page says the CMS changed, lists each changed field with the CMS value next to Mark's, and asks you to Overwrite with Mark's version or Keep the CMS version. Keeping the CMS version leaves the Mark post out of sync. Mark never overwrites a CMS edit unless you choose to.

Once a day Mark checks published pages. A page that was unpublished, deleted, or edited in your CMS shows a note on its review page. A page you took down from Mark is not flagged.

Take a page down

On a live website post's review page, Take down unpublishes it in your CMS and keeps the post in Mark. Approvers and workspace admins can use it. The page stays in your CMS as a draft, so approving the post again updates the same document. The review page, calendar, and get_post then show the delivery state taken down.

An AI agent does the same with unpublish_post (workspace admins only).

When Mark refreshes a live page because AI answers stopped citing it, an approved refresh updates the same CMS page. The URL, slug, and publish date stay the same. With Save a draft in Payload, the refresh lands as a draft of that page, and the live page changes only when you publish the draft in Payload. See Refreshes of live pages.

From an AI agent

• get_website_cms reads every connected website CMS: provider, site URL, status, publish mode, each post type's mapping, and the collections Mark found.
• update_website_cms (admins only) changes a post type's mapping on one CMS, reads the collections again, or switches back to draft mode. Pass provider when more than one website CMS is connected.
• get_post shows a website post's delivery: its state (queued, sent_to_cms, published, taken_down, failed, and the conflict states), page URL, the reason a publish failed or is retrying, a CMS conflict when the page changed there, and the document Mark sends.
• unpublish_post (admins only) takes a live page down in your CMS and keeps the post. Approving it again updates the same page.
• send_cms_preview saves a post that isn't approved yet to your CMS as a draft and returns the preview link, or the reason it can't. get_post then shows the state preview, the link, and when it was sent. When another page uses the slug, the reason names each page with its CMS id and lists the ids useCmsPageId accepts. Call it again with useCmsPageId to use that page, or change the slug with save_post.
• resolve_cms_conflict settles a CMS conflict, the same choice as Overwrite with Mark's version and Keep the CMS version on the review page. Have the agent read get_post's conflictDiff first. overwrite replaces the CMS page with Mark's version and discards the edits made there. keep leaves the CMS page as it is and leaves the post out of sync.
• sync_connections tests the connection (payload), or retries a failed publish with the job id from get_post.

No tool takes or returns the API key. The site URL and the switch to Publish live are changed in Mark only.