Idempotency
A till loses Wi-Fi mid-sale. Your code retries. Did the first request land? Without an idempotency key, the honest answer is that you cannot know — and the customer gets charged twice.
Send an Idempotency-Key header on every write that moves money — sales and payments. Generate one unique string per logical operation, not per HTTP attempt. If the same key arrives again within 24 hours, we replay the original response instead of doing the work twice.
cURL — idempotent sale
curl -X POST https://api.tajirpoint.com/api/v1/sales/sales/ \
-H "Authorization: Bearer $TAJIR_TOKEN" \
-H "X-Shop-Id: 8f1c2d3e-…" \
-H "Idempotency-Key: sale-till3-2026-07-11-000148" \
-H "Content-Type: application/json" \
-d '{
"warehouse": 1,
"items": [
{ "variant": 88, "quantity": "2.000", "unit_price": "450.00" }
],
"payments": [
{ "payment_method": 1, "amount": "900.00" }
]
}'Choosing a key
- Reuse the key when retrying the same operation — that is the entire point. A fresh key on a retry creates a duplicate sale.
- Generate a new key for a genuinely new operation, even if the payload is byte-identical. Two customers really can buy the same thing for the same price a second apart.
- Make it unique to you — a UUID, or something structured like
sale-till3-2026-07-11-000148. Keys are scoped to your shop, so you cannot collide with anyone else.
Only successful responses are cached. A request that failed with a 400 or a 500 can always be retried with the same key — so on a timeout, where you genuinely do not know what happened, retrying with the original key is always the correct move.