Confluence Cloud REST API v2 — Support partial page content updates via localId targeting

Currently, updating a Confluence page’s content via the REST API v2 (PUT /wiki/api/v2/pages/{id}) requires sending the entire page body as an ADF document on every write. There is no way to update a single node, append a table row, or modify a paragraph in isolation.

This is a significant pain point for programmatic page management — particularly for AI agents, automation scripts, and integrations that maintain living documents. A page that is 70KB of ADF must be fully reconstructed and transmitted on every minor change, which is:

  • Slow — full round-trip for every edit regardless of change size
  • Fragile — concurrent writers overwrite each other’s changes; there is no merge
  • Expensive — unnecessary payload size on every request

The ADF specification already includes localId attributes on nodes for precisely this kind of addressing. The infrastructure is there — the API just does not expose it.

Request: Add a PATCH /wiki/api/v2/pages/{id}/content endpoint that accepts one or more ADF node operations targeting nodes by localId:

  • append — add a child node to a target node
  • replace — replace a target node’s content
  • delete — remove a target node

This would make the Confluence API significantly more usable for automated and agent-driven workflows, and aligns with how modern document APIs (Notion, Google Docs) handle partial updates.

Very much required. Does anyone else have a claude skill for partial upgrades, which checks for diffs b/w the source(confluence) and latest changes being added? Something similar to github diffs. This could be an alternative until atlassian adds support for the requested endpoint.

+1. Concrete case: a 256 KB page. Appending one short section is impossible
— the only operation is “replace the entire body,” so a one-paragraph edit
means resubmitting 256 KB of ADF verbatim. Realistic outcomes are a failed
call or a silently mangled page overwriting good content.

Jira doesn’t have this problem: “You do not need to send all the fields
inside ‘fields’… Absent fields are left unchanged.” Confluence exposes a
page as one enormous field, so the same routine edit becomes an all-or-
nothing rewrite.

Asks, in order of value:

  1. Block-level targeting — address a node by localId and update just that node.
  2. An append operation — add to the end of a page without resubmitting anything.
  3. Patch-style updates, with untouched nodes keeping localIds, inline
    comments, and formatting.

Page size is currently a hard cap on whether a page can be maintained by
automation at all — and long-lived, heavily-used pages cross that line first.