If-Match ETag Precondition vs Body Version Validation for Confluence REST Write Retries

When an integration retries a Confluence REST write after a timeout, the goal is to avoid creating duplicate pages or applying the same version increment twice. Two documented optimistic concurrency controls address this constraint with different failure modes.

The first uses ETag headers returned on content resources. A retry sends the captured ETag in an If-Match header, causing the server to reject the request with 412 Precondition Failed if the resource changed in between. The second relies on the version number embedded in the request body; the server rejects the update if the supplied version does not match the current stored version. Both prevent lost updates, but the ETag path may require re-fetching the resource after a 412 to obtain a fresh precondition, while the body version path requires the client to track the expected version separately from the response headers.

Which documented mechanism offers more reliable retry semantics across Confluence Cloud and Data Center editions? Does ETag support vary enough between deployments to make body version validation the safer default? How should clients distinguish a failed first attempt from a successful one when both approaches return a conflict error?