# Preventing duplicate posts after a webhook timeout

**URL:** <https://mpsocial.com/t/preventing-duplicate-posts-after-a-webhook-timeout/163632>\
**Category:** Tools of the trade\
**Created:** [September 25, 2026, 5:29pm UTC](https://mpsocial.com/t/preventing-duplicate-posts-after-a-webhook-timeout/163632 "2026-09-25T17:29:24Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![theo\_builds](https://mpsocial.com/user_avatar/mpsocial.com/theo_builds/32/74909_2.png) [@theo\_builds](https://mpsocial.com/u/theo_builds)\
**Post date:** [September 25, 2026, 5:29pm UTC](https://mpsocial.com/t/preventing-duplicate-posts-after-a-webhook-timeout/163632/1 "2026-09-25T17:29:24Z")

</div>

A timeout between your publisher and the destination is where duplicate content usually starts. The minimal fix is to treat one stable `content_id` as the deduplication key for the entire delivery path.

For example, a CMS sends a webhook for `content_id=post_8472`. The integration creates a delivery record with status `pending`, logs the outbound payload, and sends the publish request. The destination may successfully create the post but the connection times out before the integration receives the response. A few minutes later, the CMS retries the same webhook.

Before sending again, the integration looks up `post_8472`. If a returned platform post ID was stored, it marks the retry as already delivered and stops. If the first request has no final response, it should not blindly create another post. Mark that attempt as `unknown`, log the request timestamp and payload hash, then reconcile through the destination’s available post lookup or a provider-side idempotency key if one exists.

Retries should only cover transient failures: timeouts, 429 responses, and temporary 5xx errors. A validation error or malformed payload needs a failed state and a visible log, not repeated publishing attempts.

The useful audit trail is small: `content_id`, payload hash, attempt number, request time, response status, error text, and returned post ID. That is enough to diagnose whether a failure was a true non-delivery or just a missing response.

Would you keep that delivery state inside the integration tool, or put it in a separate lightweight database from the start?

---

<div class="post-metadata">

**Author:** ![darius7](https://mpsocial.com/user_avatar/mpsocial.com/darius7/32/74907_2.png) [@darius7](https://mpsocial.com/u/darius7)\
**Post date:** [September 26, 2026, 5:33am UTC](https://mpsocial.com/t/preventing-duplicate-posts-after-a-webhook-timeout/163632/2 "2026-09-26T05:33:50Z")

</div>

I’d keep the state inside the integration tool only if it can atomically enforce a unique delivery key across concurrent retries. If it only does a lookup before inserting, two workers can both see no record and send. Otherwise, use a small database with a unique constraint on (`content_id`, destination) and make record creation the gate before publishing.