An inventory management API is a set of rules that lets one program read and change another program's stock records, with nobody typing. A website can ask the stock system how many are left, and the till can tell the website one has sold. It keeps stock right only when both sides agree which one holds the true figure.
Most guides stop at the benefits. This one works through the two choices that keep a connection right, for one Nairobi shop.
The first is pull or push; the second is what happens when a connection drops. The guide ends with what ArmPOS connects today, from its own guides.
What is an inventory management API?
An inventory management API is the part of a stock system that other software can talk to. MDN, Mozilla's reference for web developers, calls an API a contract that lets software work with a program instead of a person.
For stock, that program answers questions, such as how many of a product sit in each warehouse. It also accepts changes: a sale, a delivery, a new price.
Each kind of request goes to its own address, called an endpoint. The answer usually comes back as JSON, a plain text format both programs read.
| Part | What it says |
|---|---|
| The request | GET /products/SOAP-250/stock, with the website's key |
| The answer | {"code": "SOAP-250", "warehouse": "Main", "on_hand": 12} |
An API is not the same as an integration. The API is the door; an integration is the program, built by someone, that walks through it on a schedule or when something happens.
What does an inventory API do?
An inventory API does seven jobs, and each is a request one program sends another. The table pairs each job with the request behind it and the mistake it prevents.
| Job | The request | The mistake it prevents |
|---|---|---|
| Keep product details the same everywhere | Send each product's name, code and price to the other system | One product listed under two codes, with its stock split between them |
| Update stock | Send the new quantity after a sale, a return or a delivery | The website selling what the counter already sold |
| Read stock by location | Ask for one product's stock in each warehouse | Promising goods from a branch that has none |
| Handle variants and bundles | Send stock for each size, colour and pack | Selling a size that ran out |
| Bring in orders | Ask for new orders, or receive each one as it is placed | Orders typed in twice, or missed |
| Track movement | Read transfers and adjustments | Stock that leaves one branch and never shows in the other |
| Show what is free to sell | Send stock on hand minus stock promised to customers | Selling goods already set aside for an order |
Every job depends on one code per product on both sides. If the website calls a soap SOAP-250 and the stock system calls it 250-SOAP, no API can match them. That is why SKU management comes before any connection.
How does an inventory API work?
An inventory API moves data in one of two ways. Either the other program asks at intervals, called pull or polling, or the stock system tells it when something changes, called push or a webhook.
- A program sends a request: a question about stock, or a change to it, with its key.
- The API checks the key and the request, then answers with the data or an error.
- The stock system applies the change. A sale lowers the quantity; a delivery raises it.
- The other systems learn of it: at their next request with pull, or by a message to their own address with push.
| Question | Pull (polling) | Push (webhooks) |
|---|---|---|
| Who starts it | The other program, on a timer | The stock system, when something changes |
| How many requests | Many, and most find nothing new | One message per change |
| How stale the stock can get | Up to one interval | Until the message arrives |
| What can go wrong | Too many requests hit the API's limit | A message is lost while the receiver is down, unless it is sent again |
| What the receiver needs | A key | A public address that answers, and a way to check the message is genuine |
For example: pull or push for a Nairobi shop
For example, a phone accessories shop in Nairobi, Kenya, sells 1,500 products on its website and at the counter. Its website reads the stock system's API, which returns 100 products per request. These figures are illustrative.
| Measure | Pull every 5 minutes | Pull every 30 minutes | Push |
|---|---|---|---|
| Requests per check | 1,500 ÷ 100 = 15 | 15 | None: no checks |
| Checks a day | 24 × 12 = 288 | 24 × 2 = 48 | None |
| Requests a day | 15 × 288 = 4,320 | 15 × 48 = 720 | About 300: 200 sales × 1.5 lines each |
| Longest the website can be wrong | 5 minutes | 30 minutes | Until the message arrives |
The best seller, a phone charger, sells 3 an hour at the counter. In a 30-minute gap, about 1.5 chargers leave the shop before the website hears of it. Whenever the shelf holds one or two, the website can sell a charger that is gone.
Pulling every 5 minutes shrinks that gap but sends six times the requests, most of them for products that didn't move. Push sends a message only when stock changes. The cost of push is on the receiver, which needs an address that is always up.
The test for your own shop: multiply a best seller's sales per hour by the hours between updates. If the answer comes close to the stock you hold just before a delivery, the gap will oversell. The oversell gap for one shop selling online and at the counter is worked through in ecommerce inventory management.
Why must a stock update be safe to send twice?
A stock update must be safe to send twice because connections drop, and a program that gets no answer sends its request again. If the request said take away 2, the repeat takes away 2 more.
RFC 9110, which defines HTTP, calls a request idempotent when sending it twice has the same effect as sending it once. Such a request can be repeated automatically when a connection fails before the answer arrives. Any other request should not be, unless the sender can tell the first one never took effect.
For example, the website holds 12 bottles of a body lotion when the counter sells 2. The till sends the change, the connection drops before the answer comes back, and the till sends it again.
| The update says | First send | The repeat | Website shows | Right figure |
|---|---|---|---|---|
| Take away 2 | 12 to 10 | 10 to 8 | 8 | 10 |
| Set to 10 | 12 to 10 | 10 to 10 | 10 | 10 |
The relative update hides 2 bottles the shop still has. The absolute one is safe to repeat, which matters most on a counter that runs on mobile data.
Absolute updates carry a trap of their own. If the website and the till both set the figure, the later one wipes out a sale the other recorded.
So one system owns the stock figure and sends absolute levels to the others. Every other channel sends its sales to that owner, each with a unique reference, so a repeat can be spotted and ignored.
What does a business need before it uses an inventory API?
A business needs seven things in place before an inventory API helps it. The first two cost nothing, and the rest depends on them.
- One code per product on both sides. Match codes before you connect anything, and fix duplicates first.
- One system that owns the stock figure. Write down which one it is, and let the others report sales to it.
- A ready-made connector, or a developer. An API is for programs: without a connector, someone has to write the code that uses it.
- Keys kept secret. An API key works like a password for a program, so give each system its own and replace any that leaks.
- A test before the real stock. Try the connection on a test shop or a few products, so a mistake can't overwrite every quantity.
- A log of what was sent and what failed. Each message, its answer and its retries should be on record, or a silent failure goes unseen for weeks.
- A fallback for the days it fails. Decide how staff carry on, such as exporting stock to a file and updating the other side by hand.
A connection that sends sales without payments, returns or costs leaves the other system's figures wrong. What a link to the books must send is set out in POS and accounting integration.
When does an API pay, and when does a file do the job?
An API pays when stock changes faster than a person can copy it between systems. Below that, a file exported once a day does the same job for nothing.
| Situation | An API or connector | A file once a day |
|---|---|---|
| One shop, no website | Not needed | Not needed |
| A shop with its own online store on the same stock | Not needed: one stock, nothing to sync | Not needed |
| A shop and a separate website, a few online orders a day | Helpful | Works, if someone updates the website each morning |
| Several channels and fast sellers that fail the test above | Needed | Too slow: the gap oversells |
| Figures for the accountant | Rarely needed | Works: export to Excel each month |
| A regular customer's order sent as a list | Not needed | Works: import the list as one sale |
Running several channels and branches as one stock has its own page: omnichannel inventory management.
What ArmPOS connects today
ArmPOS doesn't document a public inventory API in its Help center today, so this page claims none. Here is what its live guides describe, and what each connection does and doesn't do.
- Its own online store. It sells from the same stock as the counter, so there is nothing to sync. An online order becomes a sale, and takes the stock, when someone confirms it: Online orders.
- WooCommerce. ArmPOS uses WooCommerce's own API: you make a Read/Write key in WooCommerce and paste the key and secret into ArmPOS. Every sync starts with a button, and products match by SKU, which is the ArmPOS product Code.
- WooCommerce's stock. Sync stock now sets WooCommerce's stock to ArmPOS's, all warehouses added up: an absolute update, the safe kind above. A sale at the till doesn't change WooCommerce until someone clicks it: Connect a WooCommerce store.
- Shopify. A Shopify link has its own guide: Connect a Shopify store.
- Webhooks. On plans with webhooks, you add an address and tick events named like sale.created, and each message is signed with the webhook's secret. A message that fails is tried again after 1 minute, 5 minutes, 30 minutes and 2 hours.
- What webhooks send today. Only Send Test reaches your address: sales, purchases and payments send nothing yet. The guide says not to build on webhooks until that changes: Webhooks.
- Files. Reports export to Excel, and a CSV of product codes and quantities becomes one sale or one purchase: Import a sale and Import purchases.
- QuickBooks. The link can't connect yet, so export your figures instead: Sync with QuickBooks.
ArmPOS's own till handles a dropped connection for its sales. If the internet drops while the POS is open, it keeps the sales on the device. It sends them when the connection returns: The POS screen.
Frequently asked questions
What is the difference between an API and a webhook?
An API answers when another program asks. A webhook sends a message by itself when something happens, so the receiver doesn't have to keep asking.
Do small businesses need an inventory API?
Only when stock changes faster than someone can copy it between systems, as the test above shows. A single shop, or one that sells online from the same stock, needs none.
Is an inventory API secure?
It is as secure as its keys, because each key works like a password for a program. Give each system its own key, keep keys out of emails and shared files, and replace one that leaks.
Does ArmPOS have an API?
Its Help center documents no public API today. Its WooCommerce link uses WooCommerce's API, its webhooks send only a test message for now, and files move data in and out.
List the systems your stock lives in today, and write down which one owns the figure. If the answer is one shop and one stock, create a free ArmPOS account. Then run the counter and the online store from the same records.
