Production access request

Sandbox keys work the moment you create them. Reading a live merchant takes three stages, in this order, and each one unlocks the next:

1. 1

   Get your app approved Developer console · Review tab

   1. You Create the ADSR app
   2. You Submit for review
   3. LithosPOS Approves the app status → APPROVED
   unlocks step 2
2. 2

   Get the merchant's approval Developer console · Access tab

   1. You Request access Merchant ID + stores
   2. Merchant Approves in back office Settings → Connected apps
   unlocks step 3
3. 3

   Create the production key Developer console · API keys tab

   1. You New production key pick merchant + stores
   2. Make production calls

You LithosPOS Merchant

Two separate approvals

App review approves your integration, once. An access request authorizes that app to read one specific merchant and the stores it selects, once per merchant. You need both before a production key can be created.

1. Submit your app for review

   In the developer console, open Apps, create an ADSR app or open your existing one, and go to the Review tab. Fill in the submission:

   Field	What to give
   Integration	What your feed does, which mall operator you report for, and how tenants enable it
   URLs	Your host or integration URL, website and any dashboard a merchant will see
   Support email	A monitored address a merchant can reach
   Walkthrough video	A short recording of the feed working against a sandbox merchant
   Privacy policy	Public policy covering merchant data

   Select Submit for review. The go-live checklist lists every field and what reviewers check.

   Then contact the LithosPOS team and tell them your app has been submitted, so a reviewer picks it up. The app moves through SUBMITTED and IN_REVIEW to APPROVED, and you are emailed at each step. If changes are requested, fix them and resubmit from the same tab.

2. Request access to the merchant

   Once the app is APPROVED, go to its Access tab and file a request:

   • Merchant ID: the LithosPOS company id the merchant gave you, for example 1033.
   • Stores: once the merchant ID is entered, the merchant’s name and stores load. Pick the stores your integration needs, or leave the list empty to ask for every store, including ones the merchant opens later.
   • Note (optional): one line the merchant will read, such as which mall and lease this is for.

   Check that the merchant name shown under the ID is the one you expect before you submit. Either way the merchant chooses which stores to share when approving, and may share fewer than you asked for. After they have approved you once, the stores they shared are ticked and locked, so you can ask for more later.

   Filing a production request before the app is approved returns developer.app_not_approved.

3. Merchant approval

   The request is approved in the merchant’s LithosPOS back office, under Settings → Connected apps → Approve. The merchant’s account owner sees your app, your organization, the stores requested and your note. They can approve as filed, approve fewer stores, or deny. LithosPOS emails them when the request arrives, and the LithosPOS team can help coordinate the approval.

   On approval, the merchant and the stores they selected are authorized for your app. A request nobody decides on expires after 30 days.

4. Create the production API key

   Back in the console, open the app’s API keys tab and select New key:

   Field	Choose
   Name	Something you will recognise later, such as mall-nightly-prod
   Environment	Production
   Merchant	The merchant that approved you. Only approved merchants are listed
   Stores	The stores this key may read. Leave empty for every approved store

   The key, lp_ak_pk_…, is shown once. Store it in your secret manager straight away. It can only read the merchant and stores it was created for, never more than the merchant currently approves. Only stores the merchant approved are accepted (developer.api_key_store_not_granted). A merchant that has not approved you is refused with developer.api_key_merchant_not_granted.

5. Call the production API

   From your backend, send the key in X-API-Key and the merchant’s id as companyId:

   curl -s "https://api.lithospos.com/v1/reports/daily-sales?companyId=1033&from=2026-07-01&to=2026-07-31" \
     -H 'X-API-Key: lp_ak_pk_7f3c91b2e84a05d6c7b1a394f8e02d5c6a7b9013'

   See daily sales feed for the row and mall integration for scheduling and reconciliation.

Adding merchants and stores later

• A new merchant: repeat steps 2–4. App review is not repeated; the app is already approved.
• More stores for a merchant you already have: file another access request for only the new stores. Approving it adds them to the existing connection. A key created with no stores selected follows the approval and reads them straight away. A key created for specific stores keeps that list, so create a new key that includes the new stores.
• Rotating a key: create the replacement for the same merchant and stores, deploy it, then revoke the old one. See API keys and merchant access.

If a merchant later disconnects your app from Settings → Connected apps, calls for them return 403 partner.company_not_granted. Stop scheduling that tenant; it is not a transient error.