The Capacities API is a stateless REST API. It has no cross-request transactions — each HTTP request is independent, and the API provides no mechanism to group multiple operations into an atomic unit that either fully succeeds or fully rolls back.
When two requests modify the same object concurrently, the result is determined by whichever write reaches the server last. There is no automatic conflict detection or merging. This is standard last-write-wins (LWW) behavior — the second write silently overwrites the first.
Example: if two processes both read an object, then both write an updated version, the process that writes last wins and the other's changes are lost.
To keep your integration free of race conditions, serialize writes to the same resource. Concretely:
2xx response).PATCH or DELETE calls against the same object or block tree.Read-only (GET) requests are always safe to issue concurrently — they do not modify state.
The safest pattern for automations that update existing objects is read → modify in memory → write, executed sequentially. Avoid holding the read result for a long time before writing, as another process may have changed the object in between.
The API does not currently expose ETags, version numbers, or conditional request headers (such as If-Match) for optimistic concurrency control. If your integration requires strict conflict detection, you must enforce ordering at the application layer.
Create a ticket on our feedback board. - Let us know if you have an idea for a feature, improvement or think there is something missing.
Request additions to the documentation. - If your questions are not getting answered, let us know and we will extend the documentation.