TallyPrime and Amazon Seller Central integration

What moves between them

Data moves from Amazon Seller Central into TallyPrime. ml-connector pulls Amazon orders and writes each one into TallyPrime as a Sales voucher against the customer ledger, with line items matched to Stock Items by SKU. After Amazon releases a settlement, the connector reads the settlement report and posts the net payout, fees, and refunds into TallyPrime as Receipt and Payment vouchers against the bank ledger, so the books reconcile to the actual disbursement. Stock Item masters can be aligned so every order line references an item that already exists in TallyPrime. The cadence is a polling schedule, since neither side pushes a usable webhook to a plain REST connector.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Amazon side it holds the Login with Amazon client ID, client secret, and refresh token, exchanges them for a one-hour access token, and refreshes the token before it expires rather than per call. Every request carries the marketplace ID and targets the correct regional base URL, since you cannot query EU orders from the NA endpoint. TallyPrime has no public endpoint, so the connector reaches its port 9000 server through a local agent the customer runs on the same machine or LAN, forwarding XML or JSON envelopes named with the SVCURRENTCOMPANY header. Orders become Sales vouchers and settlement lines become Receipt and Payment vouchers, with all dates converted to YYYYMMDD. Because TallyPrime gives no idempotency key and a repeated import creates a duplicate voucher, the connector tracks every Amazon order ID and settlement ID it has already booked and uses the Alter action to update rather than re-import. Amazon throttles with HTTP 429 under a token-bucket limit, so the connector backs off and follows the NextToken cursor through every page. The TallyPrime company must be open for any write to land, so a health check confirms port 9000 is reachable before a run.

A real-world example

A small consumer-goods seller with roughly 30 staff sells on Amazon in the US marketplace and keeps its books in TallyPrime. Before the integration, a bookkeeper downloaded the Amazon settlement report every two weeks and hand-keyed the sales totals, fees, and refunds into TallyPrime, and order-level sales never appeared in the ledger until the payout cleared. With TallyPrime and Amazon Seller Central connected, each order posts as a Sales voucher when it ships, and the settlement payout books automatically as a bank Receipt with the fees split out as a Payment. The bookkeeper stops re-keying every fortnight, and the bank ledger reconciles to the Amazon disbursement on its own.

What you can do

• •Read Amazon Seller Central orders from SP-API and write them into TallyPrime as Sales vouchers against the customer ledger.
• •Book Amazon settlement payouts, fees, and refunds into TallyPrime as Receipt and Payment vouchers on the bank ledger.
• •Match Amazon order line items to TallyPrime Stock Items by SKU so vouchers post against valid products.
• •Bridge Amazon's Login with Amazon OAuth 2.0 token and TallyPrime's local port 9000 server through a customer-run agent.
• •Poll orders and settlement reports on a schedule, tracking each order and settlement ID to avoid duplicate vouchers.

Questions

Which direction does data move between TallyPrime and Amazon Seller Central?

Data moves from Amazon Seller Central into TallyPrime. Orders and posted financial events are read from the Selling Partner API and written into TallyPrime as Sales, Receipt, and Payment vouchers. TallyPrime is the system of record for the books, so ml-connector does not push accounting entries back to Amazon.

How does the integration reach TallyPrime when it has no cloud API?

TallyPrime only exposes a local HTTP server on port 9000, which a cloud service cannot reach directly. ml-connector reaches it through a local agent the customer runs on the same machine or LAN as TallyPrime, which forwards the XML or JSON envelopes and relays the responses. The TallyPrime application must be running with the target company open for any write to succeed.

How are duplicate orders and payouts avoided without an idempotency key?

TallyPrime offers no idempotency key, and a repeated import creates a duplicate voucher. ml-connector tracks every Amazon order ID and settlement ID it has already posted and uses TallyPrime's Alter action to update an existing voucher instead of importing a second one. On the Amazon side it follows the NextToken cursor through every page and backs off on HTTP 429 so no records are missed or double-read.