Idempotency
Networks fail after the server has acted. Your request times out, and you cannot tell whether the product was created — and the safe-looking choice, retrying, is exactly what creates a duplicate.
Send an Idempotency-Key on any write:
curl -X POST https://sandbox-api.biklo.com/v1/products \
-H "Authorization: Bearer $KEY" \
-H "Idempotency-Key: erp-product-1001-v3" \
-H "Content-Type: application/json" \
-d '{ … }'
- Same key, same body → the first response is replayed. Nothing happens twice, and
the reply carries
Idempotency-Replayed: true. - Same key, different body →
409 idempotency_key_reused. The key promised one request; replaying the old answer would silently discard your new data. - A failed request does not consume the key, so you can fix the payload and retry with the same one.
Keys are remembered for 24 hours and scoped to your API key, so two integrations cannot collide.
Products are already idempotent#
POST /v1/products upserts on your external_id, so a repeat updates rather than
duplicates even without a header. Idempotency-Key covers everything else — and the
case where the response never reached you at all.
