Idempotency
Idempotency is a key concept in the BetLink wallet API integration. The Bet Placement endpoint, Void endpoint and Selection Result endpoint must all behave in an idempotent manner. BetLink's idempotency is based on the header X-Idempotency-Key
which is in the form of a UUID. This means that the endpoints should respond with exactly the same response for a request sent with the same idempotency header, no matter how many times it is received.
Most idempotent reactive APIs achieve this by keeping a log of processed idempotency keys that can be referenced upon receiving a new request. Idempotency keys should only be marked as processed if the request was responded to with a 200, regardless of whether the eventual function goal (of e.g. placing a bet) was successful or not. Any server/general exceptions experienced during processing of a request would not count as a processed key.
For the Bet Placement endpoint, this means that if the operator backend has already processed a request with the incoming idempotency header, no new bets should be saved against the user but the response should still show that the bet has been placed successfully or unsuccessfully as would have been the case with the first Bet Placement request for this key.
For the Void endpoint, this means that if the operator backend has already processed a request with the incoming idempotency header, no further bets should be voided but the response should still show that the bets have been successfully or unsuccessfully voided as would have been the case with the first Void request for this key.
For the Selection Settlement endpoint, this means that if the operator backend has already processed a request with the incoming idempotency header, no additional bet resulting should occur but the response should show that the bets have been successfully or unsuccessfully resulted as would have been the case with the first Selection Result request for this key.
Last updated