[Glossary](https://blnkfinance.com/glossary) Idempotency # What is idempotency in a ledger? Idempotency Idempotency means sending the same request twice produces one movement, not two. In a ledger that is a unique reference on the transaction. Timeouts, retries, and double clicks all resend work. The reference is what stops the second post from becoming a second credit. ## How does idempotency work? Your app creates a key before it calls the API. The ledger stores that key on the first success. A second call with the same key returns the first transaction. A new movement needs a new key. HTTP 200 on a retry is success, not a second credit. ## Idempotency vs immutability Idempotency stops duplicates at the door. Immutability stops edits after the fact. You need both. A unique reference without an immutable log still lets someone “fix” a row. An immutable log without a reference still accepts two posts for one click. ## Where do keys come from? The job id, the checkout attempt, the webhook delivery id. Generate the key in your system, not in the ledger. Do not reuse a payment reference for the refund. The refund is a different movement. Blnk requires a reference on every transaction and treats it as the idempotency key. Read the [idempotency guide](https://blnkfinance.com/blog/how-to-handle-idempotency-in-your-financial-app-using-the-blnk-ledger) for the retry cases, then put the reference in your worker before you call the API. Related terms - [Reference](https://blnkfinance.com/glossary/reference) - [Transaction](https://blnkfinance.com/glossary/transaction) - [Webhook](https://blnkfinance.com/glossary/webhook) - [Immutability](https://blnkfinance.com/glossary/immutability)