Idempotent operations can be repeated safely: doing them once or a hundred times has the same effect. PUT and DELETE in HTTP are idempotent by spec; POST is not. SET x = 5 is idempotent; x++ is not. Idempotency is a core property in distributed systems because network errors force retries, and retries that change state on each attempt are a recipe for double-charges, duplicate emails, and corrupted databases.
Designing for idempotency: include an idempotency key (a UUID per logical operation) in writes; the server stores the result of the first call against that key and returns the same result for any subsequent call with the same key. Stripe pioneered this pattern; most modern APIs follow it.
Some operations are naturally idempotent (setting a value); others need scaffolding (sending an email, charging a card). The cost of getting idempotency wrong scales with the cost of the side effect: a duplicate analytics event is annoying, a duplicate $1000 charge is a customer-support disaster.
Anywhere retries happen (mobile networks, queue consumers, webhooks), idempotency separates correct systems from broken ones. The pattern is simple in principle, easy to skip, and expensive to retrofit.
TerminalFeed's premium credit endpoint uses idempotency keys to ensure repeated submissions of the same payment do not double-mint credits.