Put the store inside your app

Your app hands us the employee it already knows. We hand back the catalog that person can order from, take the order, and push you every update. Nobody signs in twice, and what they see matches the web store because the same code decides both.

One call, and they are in

You already know who the person is. Send us the identifier you use for them and we return a session bound to it. If we have never seen that identifier before we create the account from what you sent; if we have, we resolve to the same person every time.

An account holding any back office, warehouse or platform permission is refused a store session, and the check runs again on every call rather than only when the session is opened. So an administrator promoted after their session was minted stops being able to use it, and this endpoint cannot be turned into a way into those portals.

POST /api/v1/store/session

{
  "external_id": "emp-40219",
  "email": "rosa@example.com",
  "department_code": "FIELD"
}

201  a session, that employee's
     currency, and their store

Nine calls to run a store inside your app

These act as the employee. The session decides what they can see, so your app never has to reimplement an entitlement rule.

Method	Path	What it does
POST	/v1/store/session	Hand us the employee your app already knows. Returns a session, their currency and their store.
GET	/v1/store/session	Who this session belongs to, and what it may do.
DELETE	/v1/store/session	End it.
GET	/v1/store/catalogue	The catalog that person is entitled to, with their prices and availability.
POST	/v1/store/orders	Place an order from a basket your app has been holding.
GET	/v1/store/orders	Their orders.
GET	/v1/store/orders/{number}	One order, with its timeline and tracking.
GET	/v1/store/cart	What is in that person's basket, with their balance.
POST	/v1/store/cart	Add, change or remove a line. Returns the basket and the balance.

Nine more for the systems behind it

These use a token rather than a session, and each one checks a scope. A token carries only the scopes you tick, is shown once, and can be revoked on its own.

Method	Path	Scope	What it does
GET	/v1/orders	orders:read	Orders across the tenant, filterable and paged.
GET	/v1/orders/{id}	orders:read	One order in full.
GET	/v1/exports/orders.csv	orders:read	The same data as a file, for a finance system that wants one.
GET	/v1/products	products:read	The catalog, with variants and options.
GET	/v1/inventory	inventory:read	On hand, reserved and available, per fulfilment location.
POST	/v1/inventory/adjustments	inventory:write	Write a stock movement with a reason code.
POST	/v1/receipts	receipts:write	Book goods in against a purchase order.
POST	/v1/shipments	shipments:write	Record a shipment and its tracking.
POST	/v1/imports/shipments	shipments:write	The same, in bulk, from a third party warehouse.

Endpoints18

You get told, rather than having to ask

Every change to an order is published to the endpoints you register: placed, approved, allocated, picked, packed, shipped, in transit, delivered, backordered, resumed, canceled, plus credit and transfer events. Payloads are signed with a timestamp and a shared secret, retried with backoff, and carry the employee identifier you gave us so you know who to notify. Internal notes never leave the building.

Want us to look at your app and say what the handoff would take?

Book a walkthroughHalf an hour, one order walked the whole way through.