A twenty-person company runs five to eight different tools on average. A management system, an online store, a point of sale, email, a spreadsheet, sometimes a CRM, often WhatsApp. Each one does its own job properly. The cost does not come from the tools: it comes from the space between them.

That space gets filled with people. Someone exports a file, reworks it, imports it somewhere else. Someone retypes an order from one screen into another. Someone compares two lists to work out why they disagree. None of this work produces anything: it compensates for a missing connection.

An API — an application programming interface — is what removes that space. It is how two pieces of software exchange data directly, without a human and a spreadsheet in the middle.

What an API actually removes

The gain is not only time. It has three forms, and the last two matter more than the first.

Retyping. A piece of data is entered once, where it originates, then travels. This is the visible gain, the one easily counted in hours.

Lag. Without a connection, each system holds a snapshot taken at a different moment. The store shows last night's stock, the till shows this morning's. With a connection there is only one truth, current. That lag is what produces overselling — not a lack of discipline in the team.

Disagreement. Two disconnected systems always drift apart, and nobody knows which one is right. Meetings spent reconciling two numbers disappear the day there is only one source.

The connections that pay off most

Not all integrations are equal. These produce a measurable effect, in priority order.

Connection What it removes Measurable effect
Online store ↔ stock Retyping web orders No more overselling
Point of sale ↔ management Manual end-of-day consolidation Real-time revenue
Multi-warehouse ↔ central view Phone calls between sites True availability visible
Mobile app ↔ catalogue Stale prices in the field Correct orders first time
Marketplace ↔ catalogue Manual listing updates Consistent prices and stock everywhere

The first row is almost always where to start. An online store disconnected from physical stock sells what no longer exists, and every cancelled order costs far more than the lost margin: it costs the customer.

How a synchronisation works

The principle is simple, even without a technical background. Two systems exchange structured messages, in a format both understand, through a secure address and an authentication key.

Online store               G-stock
      |                       |
      |----- new order ------>|   stock is decremented
      |                       |
      |<---- stock update ----|   the product page shows the right quantity
      |                       |
      |<---- shipped status --|   the customer is notified

Two modes exist, and the difference matters more than it appears.

Scheduled synchronisation polls the other system at a fixed interval, every fifteen minutes for example. Simple to set up, and good enough for catalogues or price lists.

Event-driven synchronisation (webhooks) pushes the information the moment it happens. Essential for stock: fifteen minutes of delay is all it takes to sell the last unit twice.

Questions to ask before choosing software

Check this before signing, never after. Closed software charges you on the day you want to leave it or build around it.

  1. Is the API publicly documented, with examples you can read without a customer account?
  2. Is it included in the subscription, or billed separately per call or per connector?
  3. Does it cover both reading and writing? A read-only API enables no real automation.
  4. Are there webhooks, or only scheduled polling?
  5. What are the rate limits, and what happens when you exceed them?
  6. How are errors and retries handled after a network outage?
  7. Is there a test environment separate from production?

Question 3 alone rules out a good share of the market. Many vendors advertise an API that only exports data; it is useful for reports, not for connecting systems.

Classic pitfalls

Connecting dirty data. If your references are not uniquely and consistently identified across both systems, synchronisation will spread the mess at high speed. Clean the catalogue before connecting, never after.

Forgetting who owns the truth. For each piece of data, exactly one system must be authoritative. Who owns the price? The stock level? The customer record? Without that decision written down, the two systems overwrite each other and the data becomes random.

Ignoring failures. The network will go down. The right question is not "how do we avoid it" but "what happens during, and what happens when it comes back". A correct integration queues messages and replays them in order.

Connecting everything at once. One integration at a time, stabilised before starting the next. Three connections launched together make any diagnosis impossible.

Where to start

  1. Draw your tools on a sheet of paper and, between them, every flow that currently passes through a human.
  2. Roughly estimate the weekly hours each manual flow consumes.
  3. Take the heaviest flow and check that both tools offer a read-and-write API.
  4. Decide, for each exchanged field, which system is authoritative.
  5. Run the connection in observation mode, compare both systems for a week, then switch over.

Where the software fits

An API is not judged by its sophistication, but by the number of spreadsheets it makes disappear between two departments.

G-stock exposes a documented REST API with read and write access to products, stock, customers, orders and movements, plus webhooks on stock and order events. The existing e-commerce connectors run on that same API: whatever a connector does, your own developer can do too.