Operate
Sandbox and going live
The sandbox simulators, the go-live checklist, and what review looks at.
The sandbox
The sandbox is a full copy of Scanimart Connect with fake stores and fake customers, at https://sandbox.api.scanimart.com. Nothing there reaches a real store, customer or settlement. Your company can use it from the moment you sign up.
Set up sandbox in the dashboard creates your test store — five stocked products, a retailer, a location in Bengaluru — and connects it to your company.
Then make things happen, from the dashboard's Sandbox page or with your company-wide test key. Store-scoped keys cannot run simulators or reset the company sandbox:
| Simulator | API | What it does |
|---|---|---|
| Paid online order | POST /v1/sandbox/orders |
A customer pays for a delivery order. You get order.placed. |
| Move an order on | POST /v1/sandbox/orders/{id}/advance |
Play the store, rider or customer: ACCEPTED, PACKED, OUT_FOR_DELIVERY, DELIVERED, CANCELLED |
| In-store sale | POST /v1/sandbox/instore-sales |
A Scan & Go basket paid in the aisle. You get sale.completed. |
| Reset | POST /v1/sandbox/reset |
Delete your test orders and restock the shelf |
lines on an order or sale picks the products: [{"barcode": "8901725181222", "quantity": 2}]. Without it you get one each of two stocked products.
The simulators run the real code paths — stock is held and taken, refunds and webhooks happen — so what works here works in live.
The go-live checklist
Live keys are turned on by a person at Scanimart, after review. Before you can ask, your sandbox activity has to show eight things. Nobody ticks these by hand; each is recorded when your integration actually does it:
| Item | How to get it |
|---|---|
| Your endpoint answered a webhook with 2xx | Any delivery, or a test event |
| Your endpoint rejected a mis-signed event with 4xx | Send test event with bad signature ticked |
| You accepted a test order | …/accept on a simulated order |
| You rejected a test order | …/reject on another |
| You retried a request with the same Idempotency-Key | Send the same accept or push twice with one key |
| You pushed stock counts | PUT …/inventory |
You booked a sale.completed |
Answer one with 2xx, or POST …/sales/ack |
Your endpoint answered an order.cancelled |
Reject an order, or advance one to CANCELLED |
The dashboard's overview shows your progress.
Requesting review
When the list is complete, an owner or admin fills in the company's legal name and contact e-mail (Settings) and presses Request review. A Scanimart engineer looks at your sandbox activity and request log — error rates, whether you retry sensibly, whether webhooks are answered promptly — and either:
- approves: live keys can be created at once, and the owner and admins get an e-mail; or
- asks for changes: the e-mail and your dashboard say what. Your sandbox keeps working; fix it and request review again.
Your first live store
- Create a live key for your server (switch the dashboard to Live), covering every connected store. Claiming codes and managing webhook endpoints need a key like this; a store-scoped key is refused with
403 key_scope_insufficient. - Register your live webhook endpoint — the live and test endpoints are separate.
- Ask the store owner to generate a code in the retailer app (Settings → POS software → Connect your POS), and claim it from your server.
- If your software runs on a PC in the shop, create a store-scoped live key for that store now and install it there.
- Push a full stock count before the store's first online order.
Watch the request log and webhook deliveries for the first day. If a store reports something odd, the Request-Id of the call and the event id are what we need to look into it.
If something goes wrong in live
Scanimart can suspend a company — every key stops and no webhooks are sent — when an integration is harming stores or customers, or a key is known to have leaked. Your owner, admins and contact e-mail get an e-mail saying so, and why; owners and admins also see Scanimart's note on the dashboard's Activity page. Reply to that e-mail, or write to developers@scanimart.com, when you have dealt with it.
Suspension is lifted by Scanimart, and the same people get an e-mail saying what access is back. Lifting it restores what you had before: a company that was live is live again, and one that was still in the sandbox goes back to the sandbox — it never turns on live keys that review had not approved. If our records do not show what you had, which can only happen for a suspension that began before we kept that record, the sandbox comes back first and live keys stay off: reply to the e-mail and we will confirm your live access. Keys revoked during the suspension stay revoked. Then replay the deliveries that failed in the meantime and catch up from GET /v1/events.
For a single leaked key, Scanimart revokes just that key instead, and e-mails the same people naming it. Create a new one; nothing else stops.
