Deta Base write idempotency limits during API retries

Handling Duplicate Writes in Deta Base

Deta Base provides a serverless NoSQL environment where data operations are performed via a REST API. While record-level updates are atomic, the standard API does not natively provide idempotency keys for complex write operations.

When an application encounters a network timeout or a 5xx error during a write request, the client cannot immediately determine if the record was successfully committed before the connection failed. Implementing a retry mechanism without a native idempotency token risks creating duplicate entries or inconsistent state if the operation is not a simple overwrite of a known key.

Given the current API behavior, what are the recommended strategies for ensuring write idempotency? Specifically, does the system provide a mechanism to prevent duplicate record creation during retries beyond manually managing unique identifiers?