The kit is at preview. Every page on this site is built from the kit's own guide. Not everything the guide describes is available yet: chapter 9 marks each extension point, and every chapter says what the kit has proven and what it has not. Read the status before you quote a customer.
What you can build
A customer's own behaviour, without changing iVendNext itself: the customer's rules at the till, the customer's own records in iVendNext Desk, links to the customer's own systems, reports and approvals, and an AI assistant on the user's own key. Chapter 1 says what each means, and chapter 16 lists what is possible today, what is possible after an extension point we are building, and what is not possible.
Start in five steps
- Request a sandbox site. We host one for you, with demo stores, tills and users. Nothing to install.
- Get the kit. The guide, the recipes, the samples and the tools are on GitHub.
- Make your app's user and key, and make the first call.
- Run a sample against your sandbox and watch it work.
- Choose your way in and build.
Each step is on the Get started page, with its commands.
The ways in, simplest first
Some of the ways in depend on extension points that are still being built. Chapter 9 says which; check it before you quote.
| Rung | Way in | What it is | Your code runs | Recipe |
|---|---|---|---|---|
| 1 | Configure | pricing, promotions, coupons, sale details, line details, till keys and layouts, receipt and label formats, workflows, numbering, permissions, reports, notifications — set in iVendNext Desk | nowhere | 4. Configure first |
| 2 | Outside app | your service reads and writes records over the API and reacts to the event feed; any language | your server or the customer's | Building a connected app · 5. Outside apps and the event feed |
| 3 | Till key | the cashier taps a key; the till calls your HTTPS service; you answer with a message or sale details | your server | A till key · 6. Till keys |
| 4 | Manifest | your own record types, fields, print formats, notifications and workspaces, declared as data and installed by us | nowhere — it is data | Shipping your own data in a manifest · 7. Manifests |
| 5 | Sandboxed function | a compiled WebAssembly function at a published extension point; the same answer on the server and on an offline till | inside a sandbox we run | 8. Sandboxed functions · the Wasm kit |
| 6 | Request an extension point | when no rung fits, ask us for a new published extension point | — | 9. The extension-point catalogue |
Combine rungs. A real project is usually several: a manifest for the records, configuration for the screens and approvals, an outside service for the logic, a till key for the cashier. Chapter 15 shows the combinations by customer size.
The four rules
Four rules, each with what to do instead. They are short on purpose: anything they do not forbid is open to you.
| Rule | Why | Instead |
|---|---|---|
| 1. Money enters the sale visibly, before payment. A price or discount may come from your service, but never change a price, tax or total after the cashier has seen it | The cashier, the receipt and the books must show the same amount. A total changed behind the till disagrees with what the cashier charged, and the sale is stopped — possibly after the card was taken | prices, promotions and coupons (configuration); a live price or discount through the deal extension point, within the shop's limits; a check before payment |
| 2. Don't override or patch iVendNext. | We upgrade every customer together. An override or a patch is a private copy of our code that the next release moves under, and on the till it is not even reached | an extension point; if none fits, request one |
| 3. Your code runs on your server. Inside the customer's site you ship data, not code — no server code of yours, no server scripts | Many customers share one installation, so code inside one site is code on all of them, and a script can send data anywhere with no review. Data installs into one site and touches no one else's | an outside app, a till key, a payment connector on your server; a manifest or a sandboxed function inside the site |
| 4. Your screens use our doors. Never your JavaScript inside Desk forms or the till | A script on a form runs in every user's browser, administrators included. The till loads only its own code | native screens, declared buttons, your page inside our frame, or your own app with Sign in with iVendNext (chapter 13a) |
What is live, and what is being built
Chapter 9 says, for each extension point, what has shipped and what has not. Our own Custom Development team is building reference apps with this guide. See Reference apps.