LithosPOS platform APIs

The LithosPOS platform API lets your software read and write a merchant’s point-of-sale data: items and menus, stock and purchasing, customers, online orders, taxes and sales reporting. Your application authenticates as itself — not as a staff user — with an OAuth2 client-credentials grant, and every call is scoped to one merchant company.

Pick a product

Access is packaged as three products. An app declares its product when you create it, and that choice is permanent — it fixes the scope bundle the token carries.

Full API Catalogue, inventory, purchasing, customers, reservations, taxes and reports. Requires app review before production access.

Online Order API Read menus, inject orders from your channel, track acceptance and food-ready state. Open to any approved developer.

ADSR API Automated daily sales reporting for malls: one canonical row per store per day.

How access works

1. Register a developer account and verify your email address.
2. Apply to the developer program (a short NDA application) and sign the developer agreement.
3. Create an organization and an app inside it. The app is issued a sandbox credential immediately.
4. Provision a sandbox merchant — a real, isolated demo company you can write to freely.
5. Mint a token with your client credentials and call the API.
6. Submit for review when you are ready for production merchants.

Steps 1–5 take a few minutes once your program application is approved. Start with the getting started walkthrough.

Base URLs

Surface	Base URL	Purpose
Token endpoint	https://api-v2.lithospos.com/v1/token	Exchange client credentials for an app token
Partner API	https://api-v2.lithospos.com/v1	Every merchant data operation
Developer API	https://auth.lithospos.com/api/v2/developer	Console side only: accounts, organizations, apps, credentials

One host serves every merchant. LithosPOS runs regional clusters (UK, US, India, UAE) and a merchant’s data lives in exactly one of them, but the gateway reads the region from your token and routes each request to the right origin — you never address a cluster directly.

Take the base URL from api_base_url in the token response rather than hard-coding it. It is the contract, and reading it is what keeps your integration working across failover and self-hosted topologies.

Everything is server-to-server

Client secrets and app tokens must never reach a browser, mobile app or anything else a merchant’s staff can read. Keep the credential exchange on your backend.

Conventions

• Envelope — successful partner responses return { "data": … }, with { "meta": { "page", "limit", "total" } } added on list endpoints.
• Errors — every failure carries a stable machine-readable code. Branch on code, never on message: messages are translated to the caller’s locale.
• Localisation — send Accept-Language and response messages come back in that language.
• Money and quantities — decimals are JSON numbers in the merchant’s own currency; there is no minor-unit conversion.
• Dates — YYYY-MM-DD for report windows, ISO 8601 timestamps everywhere else.