Learn the kit
What you can build on iVendNext, and how: the ways in, the needs customers ask for, working samples, and the reference behind them. You know what you are building? This page is the way from a placed need to a working app: the ladder, the recipe and sample for the rung, your sandbox, and the tests that let it ship.
Next: Build your first appRequest a sandbox
What you can build
What you can use
Every endpoint your app calls, every call iVendNext makes to your service, what a manifest can add and the screens you can make.
Needs catalogue
What retailers ask for, in their own words, and whether you can build it today. Not sure the need is placed? Look it up here first.
Plan a project
From a customer's list of needs to a release: the order to build them in and the limits to put in the quote.
How it all works
Where your app runs, where the data lives, and why customers never collide, in ten minutes.
Start from working code
Samples
Small working examples, each with its tests: start from the nearest one.
Build your first app
From one of the kit's samples to your customer's App library in six steps.
The ways in, simplest first
| Rung | Way in | What it is | Your code runs | Recipe |
|---|---|---|---|---|
| 1 | Configure | pricing, promotions, coupons, sale details, line details, till keys and layouts, receipt formats (label layouts printed from the till are an extension point), 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 · 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 · Till keys |
| 4 | Manifest | your own record types, fields, print formats, notifications, workspaces and every other kind the manifest recipe lists, declared as data and installed by the retailer's administrator, checked by our code | nowhere: it is data; a print format runs when it prints, some kinds call your service, a module runs in our sandbox | Shipping your own data in a manifest · 7. Manifests |
| 5 | Sandboxed function | a compiled WebAssembly function at a published extension point that offers one (the check before payment and pricing do); the same answer on the server and on an offline till | inside a sandbox we run | Sandboxed functions: the Wasm kit |
| 6 | Compose doors, then request | If no single door fits, compose doors before you ask for one. An outside app with a document check, a Desk button that asks for inputs, a partner page opened from a button, a capture at the scan, save rules and configuration combine to meet most needs. A composition with its limit stated (a separate screen, a tap, seconds of delay) is the answer to give, never a workaround to hide. Request an extension point only when no composition meets the customer's outcome, and say in the request which compositions you tried and why each falls short. | — | 9. The extension-point catalogue |
Combine rungs. A real project is usually several (and rung 6 is the same idea for one need: combine the doors you have before you ask for another): a manifest for the records, configuration for the screens and approvals, an outside service for the logic, a till key for the cashier.
The ladder and the four rules
The order to try the ways in, and the four rules every project keeps.
Manifests
The records, fields, workflows and declarations one file can add.
Extension points
Each one iVendNext publishes, and how to ask for a new one.
How the data travels
Which calls go where on each sale, in two worked examples.
Reference
Recipes
One recipe for each job, with its steps and commands.
The guide
The chapters behind the recipes and the samples.
Record types
The record types an app most often reads or writes, with their fields.
API reference
Every record call the samples make: address, method, parameters and answers.
Security and the handshake
How a retailer and your app trust each other.
Starters for local work
Starting points for a local ERP, a payment gateway, a wallet, loyalty, messaging or delivery.
The release gate
Testing and release, in the customer's own CI.
Your sandbox
Request a sandbox
Your own hosted site to build and test on.