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

**URL:** <https://community.developer.atlassian.com/t/confluence-cloud-rest-api-v2-support-partial-page-content-updates-via-localid-targeting/100286>\
**Category:** Confluence Cloud\
**Tags:** rest-api\
**Created:** [April 16, 2026, 11:44pm UTC](https://community.developer.atlassian.com/t/confluence-cloud-rest-api-v2-support-partial-page-content-updates-via-localid-targeting/100286 "2026-04-16T23:44:41Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![LaxmiOruganti](https://avatars.discourse-cdn.com/v4/letter/l/41988e/32.png) [@LaxmiOruganti](https://community.developer.atlassian.com/u/LaxmiOruganti)\
**Post date:** [April 16, 2026, 11:44pm UTC](https://community.developer.atlassian.com/t/confluence-cloud-rest-api-v2-support-partial-page-content-updates-via-localid-targeting/100286/1 "2026-04-16T23:44:41Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![RuchirKumbhare](https://avatars.discourse-cdn.com/v4/letter/r/57b2e6/32.png) [@RuchirKumbhare](https://community.developer.atlassian.com/u/RuchirKumbhare)\
**Post date:** [May 13, 2026, 7:24am UTC](https://community.developer.atlassian.com/t/confluence-cloud-rest-api-v2-support-partial-page-content-updates-via-localid-targeting/100286/2 "2026-05-13T07:24:00Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ChaseKimball](https://avatars.discourse-cdn.com/v4/letter/c/f17d59/32.png) [@ChaseKimball](https://community.developer.atlassian.com/u/ChaseKimball)\
**Post date:** [September 17, 2026, 1:20am UTC](https://community.developer.atlassian.com/t/confluence-cloud-rest-api-v2-support-partial-page-content-updates-via-localid-targeting/100286/3 "2026-09-17T01:20:47Z")

</div>

+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.