Slab ACTION

Update Post Content

Replace or edit a post's body via the updatePostContent GraphQL mutation. Content must be supplied as a Quill delta (see https://quilljs.com/docs/delta/) wrapped in an {"ops":[...]} object, passed as a JSON string — the API rejects a native/unwrapped delta object at the GraphQL layer. IMPORTANT: Slab derives the post's displayed title from the first line of its content — there is no independent title field after creation. An op with {"retain":0} (or no leading retain) inserts at the very start WITHOUT deleting anything — it pushes the existing content later in the document, so it can change what displays as the title without removing the old title text (which still exists, just no longer on the first line). To actually replace the title, delete the existing title's range — {"delete":N} where N is the old title line's length — then insert the replacement. To append body text while preserving the title, first read the post's current content (via Search Posts or Get Posts) and lead with a retain count covering the existing title line's length. This is a distinct endpoint from Update Post (which handles metadata/access only, and cannot change title). Run Search Posts first to obtain the post ID. Example (append after a 20-character title line): postId abc123, delta {"ops":[{"retain":20},{"insert":"Additional body text.\n"}]} — a non-error response confirms the edit was accepted. CRITICAL: this mutation applies your delta positionally against whatever the post's content actually is at the moment the call runs — there is no version check, and the response reflects the pre-edit snapshot, not the result. Always re-read the post's current content (Search Posts or Get Posts) immediately before computing a delta, and if you need to make a second edit to the same post, re-read again first — never compute a new delta from an earlier read or from this action's own response. Offsets computed against a stale snapshot land in the wrong place and silently corrupt the document instead of erroring; they do not queue safely. See the documentation.

Action
Writes data
API key
SDK
MCP

Start building

IMPLEMENTATION

Call this tool

Connect a user's Slab account once, then configure and run Update Post Content from your backend or agent.

Pipedream Connect

import { PipedreamClient } from "@pipedream/sdk"

const pd = new PipedreamClient({
  projectId: process.env.PIPEDREAM_PROJECT_ID!,
  clientId: process.env.PIPEDREAM_CLIENT_ID!,
  clientSecret: process.env.PIPEDREAM_CLIENT_SECRET!,
  projectEnvironment: "production",
})

const result = await pd.actions.run({
  id: "slab-update-post-content",
  externalUserId: "{external_user_id}", // any stable ID for this user in your system
  configuredProps: {
    slab: { authProvisionId: "apn_xxxxxxx" },
    postId: "Post ID",
    delta: "Delta",
  },
})

console.log(result)

curl -X POST https://api.pipedream.com/v1/connect/{project_id}/actions/run \
  -H "Content-Type: application/json" \
  -H "X-PD-Environment: production" \
  -H "Authorization: Bearer {access_token}" \
  -d '{
    "external_user_id": "{external_user_id}",
    "id": "slab-update-post-content",
    "configured_props": {
      "slab": { "authProvisionId": "apn_xxxxxxx" },
      "postId": "Post ID",
      "delta": "Delta"
    }
  }'

// accessToken: mint a short-lived token with the Connect SDK — see the MCP guide
const transport = new StreamableHTTPClientTransport(
  new URL("https://remote.mcp.pipedream.net/v3"),
  {
    requestInit: {
      headers: {
        Authorization: `Bearer ${accessToken}`,
        "x-pd-project-id": "{project_id}",
        "x-pd-environment": "production",
        "x-pd-external-user-id": "{external_user_id}", // any stable ID for this user in your system
        "x-pd-app-slug": "slab",
      },
    },
  },
)

const mcp = new Client({ name: "my-agent", version: "1.0.0" })
await mcp.connect(transport)

const { tools } = await mcp.listTools()

// listTools() hands your model this tool's input schema, so it can
// fill the arguments itself:
const result = await mcp.callTool({
  name: "slab-update-post-content",
  arguments: {
    postId: "Post ID",
    delta: "Delta",
  },
})

SCHEMA

Inputs

Pipedream supplies the connected account. Your application provides the operation-specific values below. Dynamic inputs are resolved against that user's account.

Update Post Content inputs
Property	Type	Description
`postId` Post ID	`string`	ID of the post whose content to update. Run Search Posts first to obtain the ID. Required
`delta` Delta	`string`	Quill delta describing the content change, as a JSON string wrapped in `{"ops":[...]}`. To preserve the post's title (its first content line), lead with `{"retain":N}` where N is that line's length in characters before your `insert`. Example (append after a 20-character title line): `{"ops":[{"retain":20},{"insert":"\nThis guide covers setup."}]}`. Example (replace a range, not touching the title): `{"ops":[{"retain":25},{"delete":3},{"insert":"new"}]}`. Compute N and any retain/delete counts from a `content` you just read for this specific call — a value carried over from an earlier read or a prior call to this action will target the wrong position. Validated as JSON with an `ops` array in run(), then sent to the API as a JSON string. Required

REFERENCE

Tool details

Behavior hints are published with the component in the Pipedream registry and surface as MCP tool annotations, so an agent can reason about a tool before it calls it.

Registry key: slab-update-post-content
Version: 0.0.1
App: Slab
Authentication: API key
Read-only: No
Destructive: No
Open world: Yes
Source: View on GitHub ↗

Call this tool #

Inputs #

Tool details #

Call this tool

Inputs

Tool details