Rename section

Outcome

Rename a documentation section or change its slug.

These examples were captured from the local Worker. Deployment, publication and retrieval are verified separately for each environment; local examples do not establish external provider delivery.

Before you start

• Inspect the credential identity with topolo whoami and the exact action with topolo actions get before preparing input.

• Discover an accessible Docs workspace with topolo resources topolo-docs and topolo workspaces list topolo-docs. Pass workspace resource type and identifier separately from action input.

• The published required permission is docs:write; the active credential and resource binding must authorize the call.

• Validate and plan the exact request. Execute only after the intended effect has been authorized; --confirm is the transport guard, not a grant of permission.

Discover the target

topolo actions get app_topolo_docs.sections.update --detail --json
topolo resources topolo-docs --json
topolo workspaces list topolo-docs --json
Read the document/space identity and call app_topolo_docs.spaces.sections.list for that space.

Input fields

Interpret the response

section is the updated title/slug record. The identifier and owning space are retained, so existing document section references remain valid.

Worked examples

The following inputs and responses were captured from the local Docs worker fixture. Auth and Nexus dependencies are simulated. Identifiers, URLs and timestamps are illustrative fixture values. Discover your own identifiers and choose an appropriate test resource; copying a fixture identifier does not make it valid in your environment. For workspace-bound calls, set DOCS_WORKSPACE_ID to the identifier returned by resource discovery. Run validation and planning first; the final call requires the intended effect to be authorized.

Minimal example

Save the input as payload.json:

{
  "sectionId": "docsec_9c57d921-baf8-455c-89a0-5abb407cb339",
  "title": "Token rotation"
}

CLI:

topolo actions validate app_topolo_docs.sections.update --data @payload.json --json
topolo actions plan app_topolo_docs.sections.update --resource-type workspace --resource-id "$DOCS_WORKSPACE_ID" --data @payload.json --json
topolo actions call app_topolo_docs.sections.update --resource-type workspace --resource-id "$DOCS_WORKSPACE_ID" --data @payload.json --confirm --json

MCP tool and arguments:

{
  "tool": "topolo_call_action",
  "arguments": {
    "actionId": "app_topolo_docs.sections.update",
    "input": {
      "sectionId": "docsec_9c57d921-baf8-455c-89a0-5abb407cb339",
      "title": "Token rotation"
    },
    "resourceType": "workspace",
    "resourceId": "<identifier returned by resource discovery>",
    "confirm": true
  }
}

Captured local response · HTTP 200:

{
  "section": {
    "id": "docsec_9c57d921-baf8-455c-89a0-5abb407cb339",
    "organizationId": "org_fixture",
    "workspaceId": "ws_fixture",
    "spaceId": "docspace_a09c96df-e507-4751-89c8-e6a99e496d0d",
    "slug": "integration-guides",
    "title": "Token rotation",
    "position": 0,
    "createdAt": "2026-10-03T08:07:30.422Z",
    "updatedAt": "2026-10-03T08:07:30.522Z"
  }
}

section is the updated title/slug record. The identifier and owning space are retained, so existing document section references remain valid.

Workflow example

Save the input as payload.json:

{
  "sectionId": "docsec_37f4c4e1-d416-47d7-ad57-d0a38fb678c4",
  "title": "Token rotation"
}

CLI:

topolo actions validate app_topolo_docs.sections.update --data @payload.json --json
topolo actions plan app_topolo_docs.sections.update --resource-type workspace --resource-id "$DOCS_WORKSPACE_ID" --data @payload.json --json
topolo actions call app_topolo_docs.sections.update --resource-type workspace --resource-id "$DOCS_WORKSPACE_ID" --data @payload.json --confirm --json

MCP tool and arguments:

{
  "tool": "topolo_call_action",
  "arguments": {
    "actionId": "app_topolo_docs.sections.update",
    "input": {
      "sectionId": "docsec_37f4c4e1-d416-47d7-ad57-d0a38fb678c4",
      "title": "Token rotation"
    },
    "resourceType": "workspace",
    "resourceId": "<identifier returned by resource discovery>",
    "confirm": true
  }
}

Captured local response · HTTP 200:

{
  "section": {
    "id": "docsec_37f4c4e1-d416-47d7-ad57-d0a38fb678c4",
    "organizationId": "org_fixture",
    "workspaceId": "ws_fixture",
    "spaceId": "docspace_a0013653-dabf-4831-8c11-6405b39664ca",
    "slug": "integration-guides",
    "title": "Token rotation",
    "position": 0,
    "createdAt": "2026-10-03T08:07:33.874Z",
    "updatedAt": "2026-10-03T08:07:33.966Z"
  }
}

section is the updated title/slug record. The identifier and owning space are retained, so existing document section references remain valid.

Verify the result

• Call spaces.sections.list and confirm the section reads as sent.

Errors and recovery

• HTTP 403 · organization_required: The token carries no organization scope. Re-authenticate against the organization that owns the Docs workspace and retry.

• HTTP 400 · workspace_required: No Docs workspace resolved for the caller. Call workspace.get to see which workspace is bound, then retry in that context.

• HTTP 403 · permission_denied: The credential needs docs:write on the selected Docs workspace.

• HTTP 400 · invalid_json_object: The body was missing, malformed, or carried a key the action does not accept. Send a JSON object matching inputSchema exactly — these routes reject unknown keys.

• HTTP 404 · not_found: No record in this workspace carries that id. List the resource first and use an id from the response.

Call this action again with the previous title and slug.

Evidence boundary

These examples establish local handler behavior and schema validity. They do not establish runtime permission parity, a deployed development/staging result or production completion. Preserve the actual request identifier and perform the verification reads after an authorized live call.