Flipkart Seller Marketplace Connector

The problem

Selling on Flipkart while running your books in Zoho means running two disconnected systems. Orders arrive in the Flipkart Seller portal; inventory truth lives in Zoho Inventory; revenue, commission, shipping fees and TCS deductions have to land correctly in Zoho Books before your GST returns are filed. In practice, most sellers bridge the gap with CSV exports and a person who reconciles a settlement report against a bank statement at the end of the month.

The failure modes are predictable. Stock sold on your own website is not decremented against the Flipkart listing, so you oversell and take a cancellation penalty. Orders are keyed into Zoho by hand two days late, so the sellable quantity your team quotes from is always stale. Settlement payouts arrive net of a dozen fee heads, so the deposit never matches the invoice total and someone force-fits a journal entry. None of this is a Flipkart problem or a Zoho problem — it is the absence of a bridge between them.

What ECOSIRE builds

ECOSIRE builds a connector that runs inside your Zoho org and keeps Flipkart and Zoho in continuous agreement. It is assembled from Zoho-native components: Deluge custom functions and standalone functions for the integration logic, scheduled functions for polling and reconciliation cycles, Zoho Inventory and Zoho Books REST APIs for record creation, a Zoho Creator application plus a Sigma widget for the operator console, and optional Zoho Flow flows where you want a business user to control routing without touching code.

Order ingestion

A scheduled Deluge function polls Flipkart's seller APIs on the interval you specify and creates a Zoho Inventory Sales Order for each new marketplace order. The Flipkart order ID and order item IDs are written to custom fields on the Sales Order and its line items, so every downstream record can be traced back to the marketplace and duplicate ingestion is impossible. Buyer details create or match a Contact in Zoho Books, with a marketplace-buyer contact strategy chosen during scoping — a per-buyer contact for B2C-style reporting, or a single marketplace clearing contact where you only care about channel-level revenue.

Listing and inventory synchronisation

The connector maps your Zoho Inventory Items to Flipkart listings by SKU, with an explicit mapping table for the cases where your internal SKU and your marketplace SKU differ. When available stock changes in Zoho Inventory — a sale on another channel, a purchase receipt, a stock adjustment, a transfer between warehouses — the connector pushes the revised sellable quantity to the corresponding listing. Buffer rules are configurable per item or per group: hold back a fixed quantity, a percentage, or publish zero when stock falls under a floor. If you run multiple warehouses in Zoho Inventory, you nominate which locations feed the Flipkart availability figure.

Fulfilment, shipping and returns

When a Sales Order is packed and shipped in Zoho Inventory, the connector confirms dispatch back to Flipkart and writes the tracking reference and courier to the Package and Shipment records. Cancellations raised on the marketplace flow back and cancel or short-close the Zoho Sales Order. Returns and RTOs create a Sales Return and, where your policy calls for it, a Credit Note in Zoho Books, with the inventory put back into the correct warehouse rather than silently disappearing.

Invoicing, GST and settlement reconciliation

Invoices are raised in Zoho Books against the correct Books organization, using the place-of-supply logic your accountant signs off during scoping so that CGST/SGST versus IGST is decided by ship-to state rather than guessed. HSN codes and tax rates come from the Item master. Settlement files are ingested and broken out by fee head — commission, collection fee, fixed fee, shipping, penalties, TCS — and posted as Expenses, Vendor Credits or journal entries against the marketplace clearing account, so the bank deposit reconciles to the paisa instead of being plugged.

Operator console and error handling

A Zoho Creator application gives your operations team a single screen: unmapped SKUs, orders that failed validation, stock pushes rejected by the marketplace, and settlement lines that could not be matched. Every API call is logged with request, response and timestamp. Failed calls retry with backoff and, past a threshold, raise an alert by email or Cliq so a silent failure cannot run for a week unnoticed.

Who this is for

Brands and distributors already running Zoho Inventory or Zoho Books who sell on Flipkart alongside their own store or other channels; sellers whose catalogue is large enough that manual stock updates cause overselling; and finance teams who need marketplace settlements to reconcile inside Zoho Books without a monthly spreadsheet exercise.

How delivery works

This application is built to order — nothing is downloaded and installed the same day.

1. Scoping call. We walk through your Zoho edition, the Books organizations and warehouses in play, your SKU structure, your GST registrations, your returns policy, and which Flipkart seller APIs your account is provisioned for. 2. Fixed quote and specification. You receive a written specification covering field mappings, sync direction for each object, sync frequency, and the reconciliation treatment for each settlement fee head — priced at a fixed figure with no hourly drift. 3. Build. ECOSIRE writes the Deluge functions, Creator application, widget and Flow configuration against a sandbox or a dedicated test Books organization. 4. Install in test. The connector is deployed into your test environment, run against real historical orders, and walked through with your operations and finance leads. You sign off on order creation, stock push, invoice tax treatment and settlement posting before anything touches live data. 5. Production go-live. We install into your production Zoho org, configure credentials and schedules, and monitor the first sync cycles with your team present. 6. Support window. A defined post-go-live support period covers defects, mapping adjustments and marketplace API changes encountered during that window.

Typical lead time is one working week from signed quote, driven mostly by how quickly marketplace API credentials and accounting sign-off come back.