Architectural advice needed: Headless Zoho Inventory WMS integration across 8 channels (Amazon, Flipkart, Quick Commerce)
Context: I am architecting a custom integration for a friend to use Zoho Inventory purely as a headless WMS (Warehouse Management System). They use Tally for all financials, so the strict requirement is: Zero Sales Orders in Zoho. Everything must be handled via direct API Inventory Adjustments. Right now they have a basic plan of Zoho.
They need to sync stock and automate fulfillment across 8 distinct channels:
- Amazon Seller Central (3P)
- Amazon Seller Flex
- Amazon Vendor Central (1P)
- Flipkart
- FirstCry
- Blinkit (Quick Commerce)
- Swiggy Instamart (Quick Commerce)
- Excel-based B2B / Bulk Orders
When a confirmed order happens on any of these channels, the middleware must instantly fetch it, explode any Kits/Bundles into Parent SKUs, and post a direct negative Inventory Adjustment to Zoho. Zoho acts as the master ledger and syncs the updated stock back to all channels.
I have the basic logic mapped out, but I'd love advice from anyone who has integrated these specific channels or used Zoho as a headless WMS on the following hurdles:
1. Is a "Headless WMS" approach fundamentally feasible in Zoho? Has anyone successfully bypassed Sales Orders and run a high-volume warehouse (returns, location bin mapping, cycle counts) purely on API-driven Inventory Adjustments in Zoho Inventory? Are there hidden gotchas when you don't use native Sales Orders or native Composite Items?
2. Integrating Quick Commerce (Blinkit / Instamart) & 1P (Vendor Central) While Amazon SP-API and Flipkart have standard webhooks/APIs, Vendor Central, Blinkit, and Instamart often rely on fixed PO spreadsheets or EDI. Has anyone built a reliable automated ingestion engine for these fixed spreadsheets without using expensive third-party tools like Unicommerce?
3. Handling Race Conditions & Overselling (Concurrency) If Amazon, Flipkart, and Blinkit all receive an order for the same SKU simultaneously, and we only have 2 units left. How should I handle inventory locking in the middleware before the Zoho API adjustment clears? Should I be using a distributed lock (Redis) or is standard row-locking in Postgres sufficient for this scale?
4. Returns Segregation Logic Returns come back daily from these marketplaces. The client wants to scan returned physical goods, classify them (Sellable vs. Repack vs. Scrap), and sync sellable stock back to the marketplaces. Since I am forbidden from creating native Zoho Sales Returns (RMA) to avoid financial clutter, I plan to just use positive Inventory Adjustments into virtual bins (e.g., "Quarantine Bin"). Has anyone modeled warehouse QC flows this way?
5. Storing the Master BOM (Bill of Materials) outside Zoho Since we are bypassing Zoho's native bundling, the middleware itself has to know that Combo-A = 4x Item-B + 2x Item-C. Is storing this Master BOM mapping in a standard Postgres database fast enough for real-time explosion logic, or should it be cached in memory?
6. Zoho API Limits & Rate Throttling Zoho has strict daily API call limits. If they scale to 1,000+ orders a day across 8 channels, making individual POST requests for every single Inventory Adjustment will burn through the limit. Has anyone successfully batched Zoho Inventory Adjustments via the API? Similarly, what's the best pattern (Celery, SQS) to throttle outbound stock syncs to Amazon SP-API to avoid getting throttled by Amazon?
Any advice on the tech stack (Python/Node, AWS Lambda vs. dedicated server) or architectural patterns for integrating these specific Indian e-commerce channels would be hugely appreciated. Can Zoho Flow or Zapier handle this?
