Skip to main content
Lark supports conditional writes using ETags. This gives you compare-and-swap (CAS) semantics over HTTP: write only if the data hasn’t changed since you last read it.

How it works

  1. Read data and request its ETag.
  2. When you’re ready to write, include the ETag in your request.
  3. If the data has changed since you read it (ETag mismatch), the write fails with 412 Precondition Failed.
  4. If the data is unchanged, the write succeeds.
This prevents lost updates when multiple clients or servers are writing to the same path.

Getting an ETag

Add the X-Firebase-ETag: true header to any GET request:
Response headers include the ETag:
The ETag is a SHA-256 hash of the data’s canonical JSON representation.

Conditional write

Include the ETag in an If-Match header on your write:

Success

If the ETag matches (data hasn’t changed), the write succeeds normally:

Conflict

If someone else modified the data between your read and write, you get a 412:
The response body contains the current value and the response includes the updated ETag, so you can read the new state and retry.

Retry pattern

A typical conditional update loop:

When to use conditional requests

Conditional writes are useful for:
  • Incrementing counters and balances without risking double-counts.
  • Optimistic locking: let a user edit data and reject stale writes.
  • Server-side read-modify-write operations without holding a persistent connection.
For client-side compare-and-swap, transactions in the Lark SDK provide a more ergonomic API with automatic retries.