HOW THE STORE RUNS
this page is generated from the running store, not drawn by hand. the stages below are the ones the code actually has, the counts were read when you loaded this, and a stage that is not connected to anything says so instead of showing a zero.
eight stages, in order. each one names the data it owns, where that data comes from and where it goes next. the count beside each stage was read when this page loaded.
WHAT WE SELL
16products, 81 variants
products, variants, prices and copy. versioned in the repository, so a price change is a commit with an author and a date.
FROMthe repositoryTOstorefront, stock, basket
VIAno external system. this stage is ours end to end.
WHAT IS ON THE SHELF
75skus in stock of 81
held in this instance memory. a restart clears it.
one number per sku. the only stage a warehouse system is allowed to write to, and it writes nothing else.
FROMwarehouse feedTOstorefront availability, order reservation
VIAstock feedPOST /api/inbound/stock
BEFORE THEY COMMIT
not counted on our side.held client-side by design
held in the customer browser, never on our server, until they check out. nothing to count here and nothing to leak.
FROMthe customer's browserTOcheckout
VIAno external system. this stage is ours end to end.
TAKEN
0orders
held in this instance memory. a restart clears it.
the moment a basket becomes a commitment. prices are copied onto the order and never read back from the catalogue again.
FROMcheckoutTOpayment, fulfilment
VIAno external system. this stage is ours end to end.
MONEY IN
nothing reported yet.orders paid
no provider account yet. this is a measure of wiring, not of demand.
a provider confirms, and the order carries its reference from then on. we never hold a card number.
FROMpayment providerTOfulfilment
VIAStripePOST /api/webhooks/stripe
PICKED AND PACKED
nothing reported yet.orders in the warehouse
no feed is writing here yet, so this is what we hold, not what the warehouse holds.
the warehouse moves the order through picking and packing, and pushes each step back to us.
FROMwarehouseTOshipping
VIAfulfilment feedPOST /api/inbound/order-status
ON ITS WAY
nothing reported yet.parcels out
no provider account yet. this is a measure of wiring, not of demand.
a carrier takes the parcel and gives us a tracking reference, which goes straight to the customer.
FROMcarrierTOthe customer
VIAcarrierPOST /api/inbound/order-status
DONE
nothing reported yet.completed
no provider account yet. this is a measure of wiring, not of demand.
the end of the line, and the start of the returns window.
FROMcarrierTOreturns, accounts
VIAno external system. this stage is ours end to end.
this store has no shared database and no shared code with anything else. whatever sits on the other side, a warehouse system, a spreadsheet, a nightly job, only has to produce the shapes below over plain http.
in the examples, a value that reads like a description is describing the type. the keys and the paths are exact.
Authorization: Bearer <INBOUND_TOKEN>every inbound request carries that header. when the token is not set on our side the endpoints refuse everything, because an unset secret must never mean an open door. the token is compared in constant time, so a wrong one cannot be found a character at a time.
set on-hand quantity per sku
EXAMPLE BODY
{
"at": "ISO timestamp (optional)",
"levels": [
{
"sku": "SLUK-HOOD-BLK-M",
"onHand": 12
}
]
}RETURNS
NOTES
absolute levels, not deltas. the whole push is applied in one statement.
move an order forward and attach a tracking reference
EXAMPLE BODY
{
"reference": "SL-XXXX-XXXX",
"stage": "dispatched",
"trackingRef": "AB123456789GB"
}RETURNS
NOTES
stages only move forward. cancelled puts the stock back.
pull orders that need picking
RETURNS