A property that makes the same operation safe to retry, performing it twice yields the same result as performing it once.
An idempotent operation is one where applying it multiple times has the same effect as applying it once. PUT /users/123 with the same body is idempotent; POST /charges that creates a new charge each time is not. The pattern matters in distributed systems because retries are unavoidable: a network blip, a timeout, a partial response, all force the client to retry, and if the underlying operation is not idempotent, retries cause duplicate charges, duplicate emails, duplicate provisioned resources.
Most 'mysterious duplicate' bugs in production are non-idempotent operations meeting the retry layer. Stripe's idempotency-key header is the canonical example of designing the API so the client can safely retry; if the same key arrives twice, only the first attempt is committed. Building this in from the start saves entire categories of incidents.
See the part of the platform that handles idempotency in production.