What it does
- Products. The merchandisable concept — the thing a customer thinks they are buying.
- Variants (SKUs). The stockable, sellable unit underneath a product: the specific size, colour or configuration, with its own code, barcode and attributes.
- Stock levels per facility. How many of a SKU are held at each of your depots or warehouses.
- Change history. An append-only record of every stock movement — what changed, by how much, why, and what it referenced.
No reorder points, no purchase orders, no supplier modelling, no cycle-count workflow, no low-stock automation. If you already run an ERP or a WMS, keep it — this module exists for accounts that want the delivery platform itself to hold the catalogue, and it stops at the catalogue.
How it works
A SKU and a package are different things
This distinction is the one that matters. A SKU is a catalogue identity: what kind of thing this is. A package is a physical unit in motion: this particular box, on this particular delivery, right now. One SKU corresponds to many packages over time. A package references a SKU rather than copying its description, so renaming a product does not leave a trail of stale text on historical deliveries.
Quantities only move through a recorded change
There is no path that silently overwrites a stock number. Every adjustment carries a reason — a receipt, a dispatch, a correction, a manual adjustment — and optionally a reference to the order or package that caused it. The current quantity is always fully explained by the history that produced it, which is what makes a stock discrepancy investigable rather than mysterious.
Stock is counted per facility
Quantities are held against a facility, not as a single company-wide total, so “how many of these are at the Sydney depot” is a direct answer rather than an inference. This is the seam where the catalogue meets the Warehousing module — one names the thing, the other knows where in the building it sits.
Optional by design
If you do not enable this module, order lines can still carry an opaque product reference of your own — a code from your ERP that the platform passes through without interpreting. Nothing forces you to move your product master onto the platform.
Permissions
This module has no permissions of its own yet. The codes below are the ones planned for it — they cannot be attached to an API credential until the module ships. Anything you build against the module today uses the base-platform permissions listed alongside them.
| Permission | What it allows | Needed |
|---|---|---|
| products.read | Read the product catalogue, its SKUs, stock levels and change history. Planned — not yet issuable. | Planned |
| products.write | Create and edit products and SKUs, and post stock adjustments. Planned — not yet issuable. | Planned |
| orders.read | Read orders and their line items — available today; line items can already carry an opaque product reference of your own. | Available |
| orders.write | Create and edit orders and their line items. | Available |
| facilities.read | Read the facilities that stock is counted against. | Available |
API reference
Catalog master data has no public contract yet. Today, order line items carry free-text product detail on the core orders API.
| Service | What it covers | Reference | Contract |
|---|---|---|---|
| orders-api | Orders and line items. Core platform — callable without this module. | OpenAPI description | openapi.json |
The contract above belongs to the core platform, not to this module. It is listed because it is the surface that does this work today — when the module publishes its own API, it will appear here.
Each openapi.json is the generated OpenAPI 3.1 contract, served by the service itself — it is never hand-edited, so it cannot drift from the running API. The OpenAPI description link opens the same contract as a browsable reference. Both resolve to the environment these docs are served from, so a page read on the test site links to the test contract.
Events
This module does not raise events of its own today. The events it is expected to raise are listed below so you can plan a subscription around them, but they are not yet published on the event stream.
When it ships, the module is expected to raise events on catalogue changes and on stock movements crossing a threshold. In the meantime, the package events below already tell you when physical units are created, moved and delivered — for many integrations that is the signal you actually want.
| Event | Raised when | Tells you |
|---|---|---|
| package.created | A physical unit is created for a delivery. | The package and the order it belongs to. Once a package references a SKU, this is the link between catalogue and delivery. |
| package.delivered | A package is delivered. | The package and the stop it was delivered at — the natural trigger to decrement stock. |
| package.moved | A package moves to a new location inside a facility. | The package and its new in-facility location. |
The envelope these arrive in, the delivery and retry guarantees, and every other event type are in Events & webhooks — or jump straight to the event catalog.