Loyalty Register glossary
Idempotency
The property that repeating the same request has the same effect as making it once, so a retried transaction does not post points or redeem rewards twice.
Idempotency is the property of an operation that has the same effect whether it is performed once or several times. Pressing a lit elevator button again does not call a second elevator; that is idempotent. In a loyalty system, it means that if the same “award points for order 12345” request arrives twice, the member still receives the points once. It matters because systems retry requests all the time: after a timeout, a network error or a restart, the sender often cannot tell whether the first attempt worked.
Updated · By Loyalty Register Editorial TeamRelated terms
What is idempotency in an API?
The HTTP standard, RFC 9110, calls a method idempotent when several identical requests have the same intended effect on the server as one. Reading data (GET) and replacing or deleting a record (PUT, DELETE) are idempotent; POST, the method usually used to create a transaction, is not. The standard says a client should not retry a non-idempotent request automatically unless it knows the request is in fact idempotent or can tell the first one never applied. Posting or redeeming points adds or subtracts, so it needs explicit protection.
How does an idempotency key work?
The sending system attaches a unique ID to each logical transaction, such as the order number plus the store ID. The loyalty platform stores the key with the result of the first request. If another request arrives with the same key, the platform returns the stored result and does nothing else.
Why does it matter for a loyalty program?
Without it, duplicate requests become duplicate points. In a hypothetical program issuing 10 million points a month, if 1% of accrual requests are retried and each retry posts again, the program creates 100,000 points a month that no member earned. Those points add to the liability, may be redeemed and distort reporting. Redemptions are just as exposed: a retried redemption can take points from a member twice and lead to a complaint.
Where do duplicates come from, and what should you check?
Common sources are checkouts that retry when the platform is slow, batch files reprocessed after a failure, event streams that deliver an event more than once, partner files sent twice and mobile apps that resend when the connection drops. Platform migrations add risk when old and new systems process the same transactions for a period.
Ask your vendor how it prevents duplicate accrual and redemption, and whether its APIs accept idempotency keys. Require every integration, partners included, to send a stable unique ID per transaction. Decide how long keys are remembered, since a retry can arrive hours later. And run a regular check for transactions with the same source ID posted more than once.