Deta Base write idempotency limits during API retries

Answer

Deta Base’s REST API does not provide a server‑side idempotency token, so retrying a write after a timeout or 5xx error may cause duplicate records unless the client ensures uniqueness.

Confirmed facts

• The API makes record‑level updates to an existing primary key atomic, so a retry on an update is inherently idempotent.
• Create operations or conditional writes have no built‑in deduplication, so duplicate records can appear on retry.
• No idempotency‑key header or response field is documented.

Recommended steps

1. Generate a globally unique identifier (e.g., UUID v4) for each logical write and include it in the request payload or URL.
2. If the operation targets an existing key, use a PUT or PATCH that overwrites the current value; this relies on the atomic update guarantee.
3. For creates, combine a deterministic payload hash with a client‑generated key and optionally store the hash in a separate deduplication index to detect repeats.
4. Implement exponential back‑off with jitter before retrying and inspect the HTTP status: a 201 indicates a new record, a 200 with unchanged data suggests the write was already applied.
5. Optionally use a conditional request (e.g., ETag or version token) to enforce “write‑if‑not‑exists” semantics.

Missing diagnostic detail: Is the retry intended to create a brand‑new record or to update an existing one? Your answer will determine the appropriate strategy.