Key takeaways
- No platform in this set documents a client-supplied idempotency key for its publish call — except Bluesky, the one genuine exception via a deterministic record key and a real upsert.
- Bluesky's com.atproto.repo.putRecord accepts an rkey and upserts on (repo, collection, rkey) — a retry with the same three values updates the existing record instead of creating a duplicate; both createRecord and putRecord also support swapCommit/swapRecord compare-and-swap guards.
- X's create-post call has no idempotency field, but a reconciliation path exists: reading the account's recent posts back can recover whether an ambiguous call actually succeeded.
- Pinterest is a confirmed hard negative, not merely unverified — both its Pin-create reference pages were directly checked and contain no dedup field at all; a retried identical call is expected to create a genuine duplicate Pin.
Bluesky: the one real exception
com.atproto.repo.createRecord accepts an optional, caller-chosen rkey — a retry using the same repo, collection, and rkey collides against the already-existing record rather than creating a second one. com.atproto.repo.putRecord goes further and makes rkey mandatory, behaving as a true upsert (create-or-update). Both additionally support swapCommit/swapRecord parameters for optimistic-concurrency compare-and-swap writes. This is architecturally distinctive — nothing else in this set works this way.
Everyone else: no way to prevent duplicate posts on an API retry
Facebook Pages, Instagram, Threads, TikTok, YouTube, LinkedIn, and Pinterest all lack a documented idempotency key on their publish/create-post calls. X's Posts API has no idempotency field on CreatePostsRequest either (a separate Chat/Bots capability does support idempotent, handle-based bot-account creation, but that is unrelated to tweet creation, not a workaround for it). Where recovery is possible at all, it comes from reading recently-created content back and checking whether the attempted post is already there — X's own recent-posts listing supports this; Pinterest's does not (both of its Pin-create documentation pages were checked directly and contain no dedup mechanism at all, a confirmed negative, not merely an absence of evidence). LinkedIn's delete call is documented as idempotent (a repeat delete on an already-deleted post returns 204), which does not help verify whether a CREATE succeeded. Telegram has no idempotency and no message-history read method to reconcile an ambiguous send after the fact — a GitHub feature request for idempotence against Telegram's own reference bot-api-server remains open and unresolved.
FAQ
- Which social platform API genuinely supports idempotent publishing?
- Bluesky, uniquely among the platforms checked here — com.atproto.repo.putRecord is a true upsert on a caller-chosen record key, so retrying the same call with the same key updates the existing record instead of duplicating it.
- Does X's API let you safely retry a post creation call?
- Not via an idempotency key — there is none — but recovery is possible by reading the account's recent posts back and checking whether the attempted content already appears there before ever resending it.
- Is Pinterest's lack of a dedup mechanism confirmed, or just undocumented?
- Confirmed — both of Pinterest's Pin-create reference pages were checked directly and neither exposes any deduplication field; a retried identical create call is expected to produce a genuine second Pin.
- Does deleting the same content twice ever count as idempotency?
- It demonstrates idempotent deletion, which LinkedIn documents (repeating a delete on an already-deleted post returns 204), but it says nothing about whether a CREATE call that errored ambiguously actually succeeded — the two are unrelated problems.
- Can Telegram bots recover whether an ambiguous send actually succeeded?
- No — the Bot API has no idempotency mechanism and no message-history read method to check after the fact, and a feature request for idempotent sends against Telegram's own reference server remains open and unresolved.
- Why does this matter for a scheduling tool specifically?
- Because a network timeout or an ambiguous error on a publish call is a real, recurring event at scale — without an idempotency key or a reconciliation path, the only safe options are risking a duplicate post or surfacing the ambiguity to a human, and this page shows which platforms force that choice.