What is idempotency?

Reading something is naturally idempotent. Ask twice and nothing about the world has changed.

Creating something is not. Send the same appointment twice and you have two appointments, unless the receiving system was built to notice.

The usual mechanism is a key. The sender attaches a unique identifier, and the receiver treats a repeat of that key as the same request.

It exists because networks lose responses. A request that worked, whose confirmation went missing, looks just like one that failed.

Bookings are where small businesses meet it. Two appointments in one slot is the visible face of a retry nobody knew had happened.

Say a caller books a 10:30 cleaning for Tuesday. Your booking system sends "create appointment" to the calendar at 3:02:10 pm. The calendar creates it and replies "done", but that reply is lost on a flaky connection. At 3:02:15 the sender, having heard nothing, sends the same request again.

Without protection, your calendar now holds two 10:30 cleanings for one person. Worse, the second copy might land in the next free chair and block a slot you could have sold. With an idempotency key, the first request carried a unique label, say bk_7f3a91, and the retry carries the same one. The calendar looks it up, sees it has already handled bk_7f3a91, and returns the original "done" without creating anything. Stripe's payment interface made the pattern well known with a header called Idempotency-Key, since nobody wants to be charged twice.

Duplicates leave a trail you can recognize. Look in your calendar or CRM for pairs of records with the same phone number, created within a few seconds of each other. One pair a month is noise. A cluster on a single afternoon usually lines up with a brief outage somewhere in the chain, and that pattern points to retries without keys.

When you talk to a vendor, you can skip the jargon and ask it plainly: if your system sends us the same booking twice, what happens? Good answers mention a request ID or a check for an existing record. "That shouldn't happen" doesn't count.

Deduplication is the cousin people mix this up with. Dedup cleans up afterward by merging records that look alike, and it can merge two real people who share a landline. Idempotency stops the second record from ever being written. You want prevention first, and you'll still need a little cleanup.

Double bookings are the version of this that customers notice, and the practical defense is availability read live at the moment a slot is offered.

Buffer rules around appointments absorb the narrow timing case where two callers are offered the same slot seconds apart.

Where records are pushed into your own systems, duplicate handling depends on the connection, which is another reason the native and Zapier distinction is worth reading.