Skip to content

Full API overview

The Full API exposes the whole back-office surface of a LithosPOS merchant. It is the right product for ERP and accounting connectors, catalogue management tools, inventory systems, CRM integrations and any vertical application that needs to both read and write merchant data.

A Full API token carries all 33 scopes. You do not request scopes per call — the product resolves the bundle at mint time and the token carries the result.

DomainScopes
Storesstores.read
Itemsitems.read, items.write
Categoriescategories.read, categories.write
Brandsbrands.read, brands.write
Menusmenus.read, menus.write
Modifiersmodifiers.read, modifiers.write
Meal slotsmeal_slots.read, meal_slots.write
Purchase orderspurchase_orders.read, purchase_orders.write
Stock transfersstock_transfers.read, stock_transfers.write
Stock adjustmentsstock_adjustments.read, stock_adjustments.write
Recipesrecipes.read, recipes.write
Productionsproductions.read, productions.write
Customerscustomers.read, customers.write
Reservationsreservations.read, reservations.write
Taxestaxes.read, taxes.write
Online ordersonline_orders.read, online_orders.write
Reportsreports.read, adsr.read

A call to a route whose scope is missing returns 403 partner.scope_denied naming the scope in params.

Every route hangs off the base URL returned as api_base_url, which is one global host for every merchant and every region:

{api_base_url}{resource} → https://api.lithospos.com/v1/items
ParameterTypeDefaultNotes
pagenumber11-based
limitnumber10Maximum 100
sortstringidColumn to order by
orderasc | descdesc
searchstring—Free-text match on the domain’s primary label
statusnumber—1 active, 0 inactive
fromDate / toDatestring—Date window on document lists, YYYY-MM-DD

Report endpoints use from / to for their window rather than fromDate / toDate — they take a trading-date range, not a filter on a document list.

List response
{
"data": [ /* rows */ ],
"meta": { "page": 1, "limit": 25, "total": 137 }
}

Single-resource responses are { "data": { … } } with no meta.

  • POST creates, PATCH updates. PATCH bodies are partial — send only what changes.
  • Unknown properties are rejected with 400, so a misspelled field never silently disappears.
  • Never send userId. The partner layer stamps your app as the actor on every write.
  • Reference ids (groupId, brandId, taxId, storeId, uomId) must exist in that merchant. Read them first; unknown ids return db.not_found.
  • PATCH bodies on items may carry nested collections (stores, variants, combo, modifierIds); a collection you send replaces the stored one — except stores, where only the rows you list are written; a collection you omit is untouched. Sending rate instead rewrites the price at every store. See catalogue.

Almost everything is scoped to a store. Read the list once and cache it:

Terminal window
curl -s "$API_BASE_URL/stores" \
-H "Authorization: Bearer $ACCESS_TOKEN"
{
"data": [
{ "id": 1, "name": "Brigade Road", "address": "12 Brigade Rd, Bengaluru", "status": 1, "type": 0 }
],
"meta": { "page": 1, "limit": 10, "total": 1 }
}

type is 0 for a store and 1 for a warehouse. Warehouses hold stock but do not sell, so they appear in transfers and adjustments but not in sales reports.

AreaStatus
Price-book bulk tools and item imagesBack office only. Per-store prices are set on the item itself
Outbound webhooksPlanned. Poll for now
Store and terminal administrationMerchant-managed
Writing sales or refundsSales are created by the point of sale; the API reads them
Per-scope consentThe merchant approves the app’s whole product bundle, not individual scopes. See OAuth