Most Indian e-commerce operators treat webhooks like a magic bullet. They assume the "push" from platforms like Flipkart or Amazon is a guaranteed delivery pipe. It isn't. Webhooks are volatile, and relying on them as your primary mechanism for order ingestion without a secondary "pull" architecture is how you end up with 500 unfulfilled orders during a midnight flash sale while your warehouse team sits idle staring at empty print queues.
The Anatomy of a Ghost Order
When a platform’s API gateway hiccups or an internet backbone in a regional hub drops, the webhook—the "push" signal—simply vanishes into a black hole. Your OMS doesn't see it; your WMS never gets notified of the new SKU movement.
In the FMCG category, where high-velocity cycle counting is the only thing keeping margins alive, this translates to "Ghost Orders." The customer sees 'Confirmed,' the platform shows 'Pending Shipment,' but because the webhook failed, the order doesn't exist in your local database. You don't find out until the customer calls to complain or the marketplace flags a fulfillment delay. By then, the shipping window is closed.
The "Manual Intervention" Trap
I once saw a mid-scale apparel brand attempt to manage a 4x volume spike during a seasonal sale with zero redundancy. Their middleware handled perfectly for six hours. Then, a minor routing instability on the marketplace's side caused a series of webhook drops. They didn't realize they were missing orders until the next morning’s audit. They had roughly 1,200 orders "orphaned" in the platform's cloud while their physical warehouse was already packing the scheduled batch.
They spent three days manually scraping order IDs and injecting them into the WMS via CSV imports just to catch up. It was a disaster of manual labor and broken trust metrics. This is what happens when you treat "push" logic as a standalone solution.
The Engineering Fix: Hybrid Integration Logic
You need a multi-layered recovery standard. If you aren't running a hybrid model, your fulfillment flow is structurally unsound.
- The Retry Loop with Exponential Backoff : When an incoming webhook hits your gateway and returns a 5xx error or a timeout, the system must not just "wait." It must place the payload into a Dead Letter Queue (DLQ). A separate worker process should attempt to re-process these at increasing intervals: 30 seconds, 2 minutes, 10 minutes.
- The Reconciliation "Pull" Script : This is your safety net. Every 60 minutes (or every 15 during peak), an automated script must query the marketplace’s API for all orders created in the last hour that do not have a corresponding `internal_order_id` in your database. This isn't a "preference"; it’s a mandatory audit loop.
- Idempotency Keys : To prevent double-counting when you pull data manually or retry a failed webhook, every order must be checked against a unique identifier (like the Marketplace Order ID) before it hits the warehouse floor. One duplicate entry in an FMCG pack can ruin a whole batch's inventory accuracy.
Implementation Thresholds
Don't just "automate" everything and hope the logic holds. You need clear triggers:
- High-Frequency Sync : Every 5 minutes for high-velocity SKUs (Cosmetics, Fast Fashion).
- Exception Flagging : If a "Pull" script finds more than five missing orders in a single cycle, it must trigger an immediate alert to the NOC (Network Operations Center) team.
Stop trusting the 'push.' Build your infrastructure to handle the reality of failing connections. A warehouse doesn't care about your elegant API design; it only cares if the label prints on time. Build the safety nets so they don't have to.