page

Call page.publish_article

Publish an article that has already been written — 'publish that blog post', 'send the article to our WordPress'. target 'native' publishes it on the site hosted here; 'byo' sends the article to the brand's own connected WordPress or Webflow site; 'both' does each. This is irreversible in front of readers. Call it on the ask: it raises the approval card showing where the article would land, which is the member's confirmation. If the result carries 'skipped', say plainly which half did NOT happen and why. Not for writing the article — that is page.write_article. Over the API it answers in two calls: without confirmation_id it proposes — says what would happen, returns a confirmation_id and changes, spends and sends nothing; the same arguments again with that confirmation_id, on a member's own API key, do it.

Every result names the workspace it ran in. Say which workspace the answer is about. When the account has more than one workspace and none is selected, this tool refuses with workspace_ambiguous and lists the choices — offer them, never pick one.

post/api/v1/tools/page.publish_article

Request

  • Base URL: https://app.goosybear.ai
  • URL: https://app.goosybear.ai/api/v1/tools/page.publish_article
  • Auth: HTTP bearer

Headers

x-request-idstring

Your own id for this request, echoed back and recorded on the audit trail. 1–128 characters from A–Z a–z 0–9 . _ : -, starting with a letter or digit; anything else is replaced by a generated id.

Request body

site_idstring uuid

The SITE the member means, as a site UUID. You are NOT shown the id of the site open on screen — it never appears in your context, so there is nothing to copy. When they say 'this site', 'the site I'm looking at', or name no site at all, they mean that on-screen site, and the way to reach it is: where this schema leaves site_id OPTIONAL, OMIT IT ENTIRELY — that is the primary path, not a fallback, and the turn's own surface resolves it server-side. Where the schema REQUIRES it, call page.list with name set to the site they named — it returns that one site's id, or the candidates to ask them about. Never pass a board, board-item, thread or any other id that merely happens to be nearby in the conversation — those name different objects and will be refused — and never one you composed.

routestring required

The article's route on the site, e.g. /blog/how-we-ship. page.write_article returns it.

target'native' | 'byo' | 'both'

Where to publish: 'native' puts the RevAStack site itself on the internet, 'byo' pushes the article to the workspace's connected WordPress or Webflow site, 'both' does each. Omit for 'native'.

publish_liveboolean

BYO only. Leave it out or pass false to create the article as a draft on the connected site for review; true publishes it to readers immediately, which cannot be undone from here.

confirmation_idstring uuid

Omit to propose: the first call says what would happen, returns a confirmation_id and changes nothing. To go ahead, send the same arguments again with that confirmation_id, on a member's own API key; a service account's key can propose but never confirm.

workspacestring

Which workspace to run in — its slug. Omit to use your default. With more than one reachable workspace and no default, the call is refused and the choices are listed.

Response

The call was admitted and dispatched. ok says whether the tool succeeded — a refusal the tool itself produced is still a 200, exactly as it is a successful JSON-RPC result over MCP.

OR

Changes

No recorded changes to this operation across all 4 revisions of this API.