Idempotency
Safely replay creation requests using idempotency keys to avoid double payments and transfers.
Network outages happen. If you don't know whether a creation request succeeded, replaying it without precaution could charge or pay out twice. Idempotency keys eliminate this risk.
How it works
Add a unique Idempotency-Key header (no X- prefix) to a POST /payments or POST /transfers
request. Wajub associates the result with that key for 24 hours: replaying the same key
returns the original response without recreating the resource.
curl https://api.wajub.com/transfers \
-H "Authorization: sk.xxxx" \
-H "Idempotency-Key: idmp_3pQ9aZ7Zk1" \
-H "Content-Type: application/json" \
-d '{ "amount": 100000, "beneficiary": {"phone": "237670000000", "channel": "cm.mtn", "name": "Amina"} }'Rules
Idempotency-KeystringoptionalScopestringoptionalWindow24 hoptionalConflict422optionalNot X-Idempotency-Key
The header is Idempotency-Key, with no X- prefix. (X-Idempotency-Key is a different,
internal header used only for inbound provider-webhook ingestion — it has nothing to do with
the merchant-facing API.)
One key per business intent
Generate the key at the moment of intent (e.g. on the "Pay" click), not on each network attempt. This way all retries of the same action share the key and remain idempotent.
Verify replays
In Konsole → Request Inspector, responses served from
the idempotency cache are marked with a replayed badge.