In this guide 7 sections
WooCommerce exposes orders, customers and products through a REST API, and Tally accepts XML over HTTP. A connector reads the first and writes the second. Decide whether to post orders or daily totals, map products and taxes, handle refunds as credit notes, and keep the API keys under a read-only role where you can.
What each side offers
WooCommerce’s REST API documentation lists orders, customers, coupons, refunds and products, with create, read, update and delete operations and batch calls. Results come in pages, 10 to a page by default, so a connector must loop through them.
Tally can receive XML over HTTP once its server is switched on in the advanced configuration. The default port is 9000, and the help pages describe import and export request types.
Neither side talks to the other directly. A small service in between does the reading, the mapping and the posting.
Authentication and safety
WooCommerce keys can be created in the admin. Over HTTPS you can use basic authentication with the key and secret, and the documentation requires OAuth 1.0a over plain HTTP. Use HTTPS.
Give the connector the narrowest permission it needs. A key that only reads orders cannot change prices by accident.
Keep Tally’s port off the public internet. Run the middleware on the same network as Tally, or use a secure tunnel your IT person controls.
Mapping products, taxes and stock
Products and variations need matching Tally stock items. Decide whether stock is held in Tally, in WooCommerce or in both, and name one as the owner. Two owners will disagree sooner or later.
Tax lines on a WooCommerce order must map to GST ledgers in Tally. Confirm rates, place of supply and invoice rules with your accountant, since these decide the voucher.
Coupons, shipping charges and payment gateway fees each get a ledger so that vouchers balance.
- Product or variation ID to Tally stock item
- Tax class to GST ledger
- Coupon and shipping ledgers
- Gateway fee and clearing ledgers
Refunds, status changes and failures
Post a voucher only when an order reaches the status you agree on, such as processing or completed. Posting at “pending” creates sales that later vanish.
A refund becomes a credit note or sales return. An order cancelled before posting simply never reaches Tally.
Each post to Tally returns a success or failure status. Log it, retry failures in order and alert a person when the same order fails twice.
Check it against reality
After a test week, compare daily order totals in WooCommerce with sales in Tally. Then compare gateway payouts with bank entries.
Repeat monthly for a few months. Mapping errors tend to show up with rare cases, such as a bundle or an international order.
If your store has custom checkout fields or several warehouses, plan for extra mapping work.
WooCommerce to Tally readiness checklist
A one-page checklist. It names the order statuses that trigger a voucher. It also names the REST key owner and permission level, the mapping owners, the system that owns stock and the failure alert contact. The last line is the weekly totals check.
Open a blank worksheet to printQuestions owners ask
Does WooCommerce have a ready API for this?
Yes, a REST API for orders, customers, products and more. It does not post to Tally by itself, so a connector must translate the data into Tally’s XML.
Where should stock be held?
Pick one owner. Many stores keep selling stock in WooCommerce and post purchases and adjustments in Tally. Others make Tally the source. Avoid both editing the same quantity.
How are refunds handled?
As credit notes or sales returns linked to the original order, posted when the refund is recorded in WooCommerce.
Is it safe to expose Tally to the internet?
Avoid it. Keep the Tally port on your own network and run the connector there or behind a secure tunnel.
Sources
- TallyPrime Help: Getting Started with Tally Integrations — verified 8 Nov 2026
- TallyPrime Help: XML Integration — verified 8 Nov 2026
- WooCommerce REST API documentation — verified 8 Nov 2026