We’ve configured a webhook in Creatio 8.2 Integration Hub to receive order updates from our e-commerce platform. The webhook works, but it’s firing multiple times for the same event, creating duplicate records in our Order entity. We’re seeing 2-4 duplicate entries for each order update.
The webhook endpoint is standard REST API, and we’ve confirmed the source system is only sending the webhook once (checked their logs). The issue seems to be on the Creatio side - either the webhook is being processed multiple times, or there’s a retry mechanism that’s not checking for idempotency.
Log snippet showing the problem:
Webhook received: OrderID=12345, EventType=status_update
Processing started: 2025-01-22 11:23:15
Record created: OrderID=12345, Status=shipped
Webhook received: OrderID=12345, EventType=status_update // Duplicate!
Processing started: 2025-01-22 11:23:18 (3 seconds later)
Record created: OrderID=12345, Status=shipped // Duplicate record
I need to understand webhook idempotency handling in Integration Hub, whether there are retry configuration settings I’m missing, and if the event source logic needs modification to prevent this. Data integrity is critical for our order processing.
Look at your webhook processing business process in Creatio. Are you using any parallel processing or async elements that might cause race conditions? Sometimes multiple instances of the same process can start simultaneously if the webhook arrives during a specific timing window. Add a process-level lock using a dedicated entity that tracks in-progress webhook processing. Before creating records, check if that webhook is already being processed by another instance.
Don’t forget about network-level retries too. If there’s a network hiccup between the e-commerce platform and your Creatio instance, the webhook might be sent multiple times at the TCP level even if the application layer thinks it only sent once. This is why idempotency is non-negotiable for webhooks. Also, log every webhook receipt with a unique identifier before any processing starts - this helps you debug whether duplicates are coming from the source or being created internally.
I’ve dealt with this exact scenario. The Integration Hub can sometimes trigger the same webhook handler multiple times if there’s an error during processing that doesn’t throw a proper exception. Implement a database-level unique constraint on your Order entity using a combination of OrderID and a webhook identifier. This way, even if the webhook fires multiple times, the database will reject duplicate inserts. It’s a safety net that prevents data corruption even if your application logic has issues.
Thanks for the suggestions. I checked the e-commerce platform’s webhook configuration and found they have a 30-second timeout with automatic retry. Our processing was taking 35-40 seconds, causing retries. That explains some duplicates, but not all. I’ll implement the idempotency key approach.