Inventory API notes
This page is for the developer whose system reads BigLedger’s stock or moves it: which document moves
stock, which figure to synchronise against, and what to read after FINAL. It is the inventory part
only. There is one API for the whole platform, with no separate Inventory API and no separate host
for it, so the path grammar, access endpoints, authentication, paging, response envelopes and error
codes are on the developer integration path.
The fast path for an integration that reads or moves stock:
- Synchronise against the stock balance, never availability, which is recomputed on every call (Reading stock: three different questions).
- To move stock, choose the document type that moves it: the server sets the signum, so a field value cannot.
- Put your own reference number on each document and check for it before posting; after
FINAL, poll the document’s inventory posting status before you read the balance.
The document types this module produces
Most of them are generic documents, reachable through the generic document endpoints by their server document type:
INTERNAL_OUTBOUND_STOCK_TRANSFER · INTERNAL_INBOUND_STOCK_TRANSFER ·
INTERNAL_STOCK_ADJUSTMENT · INTERNAL_STOCK_REQUISITION ·
INTERNAL_PURCHASE_CONSIGNMENT_GRN · INTERNAL_PURCHASE_CONSIGNMENT_GIN ·
INTERNAL_CUSTOMER_CONSIGNMENT_OUT · INTERNAL_CUSTOMER_CONSIGNMENT_IN ·
INTERNAL_GOODS_DELIVERY_NOTE
Each applet’s reference page names the four API permissions its document type needs.
Stock Conversion is not a generic document. It has its own tables, its own posting endpoint and its own pair of job processors, and its lines carry a literal string rather than an entry in the server document type enumeration. Nothing about it passes through the generic document engine, the knock-off queue or the journal.
Reading stock: three different questions, three different endpoints
| You want | Read | Note |
|---|---|---|
| What is physically on hand | the current location and current company stock balance resources | This is a stored figure, the tip of the ledger chain |
| What can still be promised | the stock availability service | Computed at query time — balance plus the signed open documents. It is not stored anywhere, so there is no table to read it from |
| What happened | the stock transaction line ledger | One signed row per movement, with the document behind it |
Two things an integration must respect
The quantity signum is the server’s, not yours. A document type’s quantity and amount signums are fixed in the backend. The applet’s own copy is overwritten by the server on every save, so sending a signum through the API changes nothing. If you need a document to move stock, you need a different document type, not a different field value.
A balance changes asynchronously. Setting a document to FINAL queues the work; the stock
processor writes the ledger line and a second processor applies it to the balance. An integration
that finalises a document and immediately reads the balance can legitimately see the old figure. Poll the
document’s inventory posting status rather than reading straight back: the _UPDATED webhook is sent when
the FINAL is saved, before the stock processors run, so it does not say the balance has moved.
Idempotency is already handled, on one path
Every ledger line applied to a balance is recorded in an applied-marker table, so a re-run of the balance processor skips a line it has already counted rather than counting it twice. That protects the processor — it does not protect you from posting the same document twice through the API. Use your own reference number on the document and check for it before posting.