Why Your Website Doesn't Know What's in Stock

Here is a morning that happens in thousands of Indian businesses. A customer orders two units on your website. The website emails you. Someone opens Tally and makes an invoice, typing the customer's name and address again. Someone else opens the stock register and reduces the count, or forgets to. The enquiry that started all this is still sitting in a WhatsApp thread on the sales person's phone. By evening, the website is still advertising four units in stock when there is one, and nobody can tell you how many enquiries turned into orders last month without an hour of reading through messages.

Nothing here is broken. Every individual system works. The problem is that you are running four separate memories of the same business, and a human being is the only wire connecting them. That human is the slowest part, the most expensive part, and the part that takes leave.

The real cost of re-typing

Owners usually think of this as a time problem. It is partly a time problem — but the time is not the expensive bit. The expensive bit is that each re-typing is a chance for the two systems to disagree, and once they disagree, nobody knows which one is right.

• The website says the item is available. Your godown says it went out last Tuesday. The customer has already paid.
• The invoice has the customer's name as "Sharma Traders". The CRM has "Sharma Trading Co". They are one customer, and your reports think they are two.
• A payment came in on UPI. The accounts person sees it. The sales person chasing the same customer does not, and sends a polite reminder for money already received.

None of these are dramatic. They are small, constant abrasions that make you distrust your own numbers. When an owner tells me "I don't really look at the reports, I just know roughly", this is almost always why.

What an API actually is

API stands for Application Programming Interface. Ignore the words. Think of it as a counter with a fixed set of forms.

Imagine your accounts department. You cannot walk into it, open a drawer and rearrange a ledger. But there is a counter, and at that counter you may submit specific requests: create an invoice with these line items, tell me the outstanding balance for this customer, mark this invoice as paid. Each request has a fixed form to fill in. If you fill it correctly, you get a predictable answer back. If you fill it wrongly, you get it back with an error and nothing changes inside.

An API is that counter, for software. When a developer says "the payment gateway has an API", they mean the payment gateway has published a list of requests it will accept from another program, and the exact format each one takes. Nothing more mysterious than that.

Two details matter to you as the person paying for the work:

The counter has to exist. A system without an API has no counter. Your only option is a person carrying paper between rooms, or a fragile workaround. Desktop Tally is the classic Indian case — it is not a web service, but it does listen for XML requests on the machine it runs on, which is how most Tally connectors work. That means that machine has to be switched on and reachable. That is a real constraint, not a detail to discover in month three.

The counter answers with a code. Every request comes back with an HTTP status — 200 means accepted, 401 means your credentials were rejected, 429 means you are sending requests faster than allowed, 500 means something broke at their end. A properly built integration reads these and reacts. A cheaply built one assumes everything worked and moves on, which is how you end up with a week of silently missing orders.

The four ways systems actually talk

When someone quotes you for "integration", they are proposing one of these four. The word covers all of them and they are not remotely equal.

Method	How it works	Honest verdict
A person	Someone reads one screen and types into another	Fine below a certain volume. Genuinely fine. Stop reading if this is you.
File export/import	Export a CSV from one system, import to the other, daily or weekly	Cheap, ugly, surprisingly durable. Good for reports and month-end. Useless for stock counts.
A connector tool	A middleware service watches one system and pushes to another	Fast to set up, monthly fee forever, breaks quietly when either side changes.
Direct API work	Custom code speaking to both counters, with error handling and logs	Most expensive, most controllable. Worth it only for the one or two flows that actually hurt.

Push versus pull

Two ways a system learns that something happened elsewhere. Polling means asking repeatedly — "any new orders? any new orders?" — every five minutes. Simple, slightly delayed, and it burns through request limits. Webhooks mean the other system calls you the instant something happens. Faster and cheaper, but if your server is down for ten minutes when the call comes, that message may be gone forever unless the sender retries. Ask which one is being used and what happens to a message that fails. If the answer is vague, the integration has no memory, and one power cut will cost you orders.

What not to buy

Being honest about our own category:

Do not buy "we'll integrate everything". A proposal that lists seven systems connecting to seven systems is a proposal to build forty-two pathways, each of which can break. Nobody needs that. Pick the one flow that is costing you money and build that properly.

Do not buy real-time sync where you do not need it. Real-time is where the cost is. Your website needs live stock counts if you sell fast-moving items to strangers. Your accounting ledger does not need to update within four seconds — once a night is plenty, and once a night is dramatically cheaper and more reliable.

Do not buy a replacement of everything. The suggestion that you rip out Tally and your existing processes for one unified platform is usually driven by the fact that unified platforms are easier to sell and carry licence margin. Migration is the highest-risk project a small business can take on. Connecting what you already use is boring and far safer.

Be very careful about scraping. If a system has no API and someone proposes a script that logs in and reads screens, understand that it will break whenever that screen changes, and it may violate the terms you agreed to. Sometimes it is the only option. It should never be sold to you as a proper integration.

Where to start

Before anyone writes code, do this on paper. Take the last ten orders and draw every point where information changed hands. Where did someone type something twice? Where did a number have to be looked up in another system? That map is your specification, and you can make it yourself in an afternoon.

Then apply one test to each step: if this step goes wrong, does a customer notice? Wrong stock on the website — customer notices. Wrong ledger grouping — only your CA notices, next quarter. Fix the first kind first.

A few practicalities that decide whether the thing survives:

1. Agree on one identifier. Every customer and every order needs a single ID that both systems use. Matching on name or phone number will fail the day someone types a space differently.
2. Insist on a log you can read. Not developer logs — a simple screen showing what was sent, when, and what came back. Without it, "it's not syncing" is unanswerable.
3. Decide what happens on failure. Does it retry? Does it queue? Does someone get a WhatsApp message? An integration with no failure plan is a trapdoor.
4. Make it safe to repeat. If the same order gets sent twice because of a retry, the second one must be recognised and ignored, not billed. Ask for this explicitly.

The bit nobody can promise you

Integrations rot. Not because they are badly built, but because the systems at either end keep changing — a payment provider updates its authentication, a platform retires an old version of its API, someone changes the GST rate on a product and a field that used to be optional becomes mandatory. Anyone telling you an integration is a one-time build is either inexperienced or not planning to be around. Budget for occasional maintenance the way you budget for servicing a vehicle. It is not a flaw in the work.

The same applies to compliance-adjacent flows. E-invoicing rules and turnover thresholds in India have shifted more than once, and the invoice reference number and signed QR code returned by the government portal have to land back in your own records correctly. Build those flows so a human can check and correct them, not so they run invisibly.

What to do next

Map your last ten orders this week. Find the single re-typing step that causes the most arguments. Cost it roughly in hours per month and in customer complaints. That one number tells you whether this is a ₹0 problem you should keep doing by hand, or a project.

If it is a project, we can look at what your current systems actually expose before anyone quotes a build — sometimes the counter you need already exists and nobody has used it. Read more about our approach to business automation and CRM systems, or see how we handle web development when the website has to know what the warehouse knows. If you would like us to look at your specific setup, get in touch and bring the map you drew.

Questions we get asked