Go-live checklist

Sandbox access is self-serve. Production access is reviewed: LithosPOS merchants are live businesses, and an app that writes to their catalogue or injects orders into their kitchen is trusted with their trading day.

Review states

State	Meaning	Who moves it
DRAFT	Created, never submitted	You
SUBMITTED	Waiting to be picked up	You submit
IN_REVIEW	A reviewer is working through it	LithosPOS
CHANGES_REQUESTED	Specific items need fixing, with notes	LithosPOS
APPROVED	Production credential issued	LithosPOS
REJECTED	Not approved in its current form	LithosPOS

You can resubmit from DRAFT, CHANGES_REQUESTED or REJECTED. Every transition is emailed to the organization and recorded on the app.

The submission

Apps → your app → Review collects:

Field	Required	Notes
description	yes	What the integration does, which merchants it serves, and how they enable it
appUrls	yes	Public URLs — product page, dashboard, marketplace listing
supportEmail	yes	A monitored address a merchant can reach
supportPhone	no	For urgent trading-hours issues
demoVideoUrl	yes	A short screen recording of the integration working end to end
checklist.usesSandboxTested	yes	You have run the full flow against a sandbox merchant
checklist.handlesErrors	yes	You handle the documented error codes, including 429
checklist.storesSecretsSecurely	yes	Secrets live server-side, in a secret store, never in a client
checklist.privacyPolicyUrl	yes	Public privacy policy covering merchant and customer data
checklist.termsUrl	no	Terms of service, if you publish them

Before you submit

1. Exercise the whole flow in sandbox

   Mint a token, run every endpoint your app calls, and confirm the result in the sandbox merchant’s back office. Reviewers replay your demo video against the endpoints your app is scoped for.

2. Handle the documented failures

   At minimum: 401 (re-mint once, then stop), 429 (wait for X-RateLimit-Reset), 403 scope and grant errors (surface them to the merchant, do not loop), and validation 400s (show the message — it is already localised). See errors.

3. Prove secrets stay server-side

   Client secrets and app tokens must never appear in browser code, a mobile bundle, a support log or a screenshot. Store them in a secret manager and read them at runtime.

4. Build request URLs from api_base_url

   Take the base URL from the token response for every request instead of hard-coding api.lithospos.com. Reviewers check for this: a hard-coded host survives today’s single-gateway topology but breaks during failover, a regional migration, or on a self-hosted deployment.

5. Scope your writes

   Write only what your integration needs. An ordering integration that rewrites the merchant’s tax configuration will be sent back with changes requested.

6. Prepare the merchant connection

   Full API and Online Order API apps: register the production redirect URIs your Connect LithosPOS button will use — up to five, exact-match, https:// only — and run the consent flow against a sandbox merchant first. ADSR apps: decide who holds the API key, where it is stored, and how you will rotate it, before it exists.

7. Make the merchant’s exit clean

   A merchant can disconnect you from their back office at any time, and your app should offer the same. Leave their data consistent when it happens, stop calling immediately, and document the behaviour in your description.

After approval

LithosPOS issues a production credential for the app — a lp_app_pk… client id and a secret shown once, exactly like the sandbox one. Nobody at LithosPOS connects merchants for you after that. Approval is what makes your app eligible to be connected; the merchants do the connecting.

Full API and Online Order API. Put a Connect LithosPOS button in your product. It sends the merchant to the LithosPOS consent screen, their account owner approves, and your app receives an authorization code it exchanges for tokens. Register your production redirect URIs before you ship the button — the authorize endpoint matches them exactly. See Connect merchants with OAuth.

ADSR API. Create a production API key and file an access request per tenant, naming the company and the stores. The tenant’s account owner approves it — possibly with fewer stores than you asked for — in their back office. See API keys and merchant access.

Either way:

• There is no administrator grant step and no ticket to raise. Adding a merchant later is a consent or an access request, not a new review.
• A merchant can disconnect you at any time from Settings → Connected apps, without warning. Handle invalid_grant / partner.grant_missing as a permanent stop for that merchant, not as an error to retry.
• Rotation, revocation and IP allowlists work as documented in authentication.

Approval covers what you described

The review is of a specific integration. Materially changing what the app does — new domains written, a new merchant-facing surface, a different data-retention posture — warrants a fresh submission. Changing the app’s product is not possible at all (developer.product_immutable); create a new app instead.

If changes are requested

The reviewer returns a list of items, each with a note, visible in the console and included in the notification email. Fix them, update the submission and resubmit — the app returns to SUBMITTED and keeps its history, so the next pass only looks at what changed.