Browse the docs

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

  1. 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.
  2. Register your live webhook endpoint — the live and test endpoints are separate.
  3. Ask the store owner to generate a code in the retailer app (Settings → POS software → Connect your POS), and claim it from your server.
  4. If your software runs on a PC in the shop, create a store-scoped live key for that store now and install it there.
  5. 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.