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-v2.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. Make the merchant’s exit clean

   A merchant must be able to disconnect your integration and be left with consistent data. Document how in your description.

After approval

LithosPOS issues a production credential for the app and creates grants for the merchants you are authorised to serve. From then on:

• The production secret is shown once, exactly like the sandbox one.
• Each merchant needs its own grant. Adding a merchant later is a grant request, not a new review.
• merchant_id is always required in production — there is no single-merchant inference.
• 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.