Idempotency is the property that performing the same operation more than once has the same effect as performing it once.
Idempotency in APIs
In HTTP, GET, PUT, and DELETE are defined as idempotent: repeating them does not change the result further. POST, which creates things, is not. Send the same POST twice and you may create two records.
That matters because networks fail in ambiguous ways. A request times out, and the client cannot tell whether the server did the work. Retrying risks a duplicate; not retrying risks a missed action.
The usual fix is an idempotency key: a unique value the client generates for each logical operation and sends in a header. The server remembers keys it has seen. If the same key arrives again, it returns the original result instead of doing the work a second time.
An example
A scheduler posts to Mastodon, and the connection drops before the reply arrives. It retries with the same Idempotency-Key header. Mastodon recognizes the key and returns the existing post rather than publishing it again.
Why it matters for AI-agent publishing
A duplicate post looks careless, and a duplicated thread looks worse. Agents also retry tool calls when they are unsure, which multiplies the risk.
SocialHandoff uses idempotency keys on Mastodon, which supports them natively, and duplicate protection on every network, so retries after a timeout or a rate limit do not double-post. Inbound webhooks are handled the same way, since senders may deliver an event more than once.