Build on iVendNext. Own what you build.
iVendNext, the open retail platform, gives you a retail POS API, an event feed of what happens in the stores, documented extension points and an open kit on GitHub. Build in any language, on your own server, with your own AI.
# get the kit git clone https://github.com/ivendnext-developers/partner-kit.git # read five items from your sandbox site curl -s "https://your-sandbox/api/resource/Item?limit_page_length=5" \ -H "Authorization: token key:secret" # the answer {"data": [{"name": "PH-128-BLK"}, {"name": "EARBUD-W"}, ...]}
Start with the simplest way that does the job
Most needs stop at the first two. A real project often combines several: a manifest for the records, configuration for the screens, an outside service for the logic, a till key for the cashier.
- Way in 1
Configure
Settings, workflows, print formats, numbering, permissions, reports and till screens in iVendNext Desk and POS Studio. No code.
Your code runs nowhere - Way in 2
Outside app
Your own service, in any language, on your own server. It reads and writes records over the REST API and reacts to the event feed of what happens in the stores.
Your code runs on your server - Way in 3
Till key
A key on the till that calls your web service and shows the cashier a message, or adds details to the sale.
Your code runs on your server - Way in 4
Manifest
Your own records, fields, print formats, workflows and numbering, shipped as data that the retailer's administrator installs.
Your code runs nowhere: it is data - Way in 5
Sandboxed function
Logic compiled to WebAssembly that runs on the till itself, even when the network is down, at an extension point that offers one.
Your code runs in a sandbox we run
When a need goes beyond these five, request a new extension point. Once it is built, it joins the platform for everyone. See the extension-point catalogue.
From a POS sandbox to your first app
A sandbox site is your own iVendNext site, hosted by us, with demo stores, tills, staff logins, a catalogue and customers. There is nothing to install. You build and test there before you touch a retailer's site.
Our team talks to every builder first, then sends your site's address and logins.
- Request a sandbox site. We host it for you, in your name.
- Get the kit. The guide, the recipes, the API description, the tools and the samples are one repository 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. The kit's check tells you before anyone else sees your app whether it keeps the rules.
Everything you need to build on the retail platform API
The kit is open source. Read it, run it and copy from it before you talk to anyone.
The guide and recipes
A chapter for each way in, a recipe for each common job, and the limits to know before you quote a retailer.
Read the guideThe API, described
Every operation of the REST API in a machine-readable OpenAPI file, a request collection, and the event feed for any language.
See the API referenceFifty worked samples
Small working examples, most with tests you run on your laptop: a warranty check at the till, bin locations, a price audit, a tax receipt, approvals, a BI feed and more.
Browse the samplesThe AI builder kit
Instruction files for coding assistants, a prompt recipe for each way in, and one check your assistant runs before it deploys.
Build with your AIThe needs catalogue
What retailers ask for, in their words, each with the way in that meets it and the recipe to start from.
Find a needDescribe it. Your AI builds it. Our checks keep it safe.
Point your coding assistant at the kit's instructions. It learns the five ways in and the four rules, builds what you describe, and runs the kit's checks before anything reaches a store. Use Claude, ChatGPT, GitHub Copilot or a free open model: nothing ties you to one AI vendor.
# tell your assistant where to start Read AGENTS.md first, then build a till key that shows the warranty terms for phones. # the assistant checks its work before deploying python3 tools/check/check.py my_app/
Four rules, and a contract that holds through every upgrade
Every extension point, API call and manifest format carries a version. From the general release of iVendNext POS, 2.0.0.652 of 18 October 2026, each version is served for 12 months after its successor ships.
- Money enters a sale visibly, before payment.A price or discount may come from your service, but a total never changes after the cashier has seen it.
- iVendNext's own code stays as shipped.Apps add; they never patch. That is how every retailer is upgraded at once.
- Your code runs on your server.Inside the retailer's site you ship data, not code.
- Your screens use the doors we document.Native screens, declared buttons, your page inside our frame, or your own app with Sign in with iVendNext.
Anything the rules do not forbid is open to you. Read the four rules in full.
Build apps for a retail platform, and keep them
We build the platform and the standard version of a shared need. You build everything around it, and we say in advance what we will build. What you build is yours: set your own price and bill your own customers.
- You
Get a sandbox and the kit
Your own sandbox site, and the open kit from GitHub.
- You
Build with the kit
Take the simplest way in. The check shows what the retailer will be asked to agree to.
- You
Publish to your customer
Your app lands on that retailer's private shelf in the App library.
- You or CitiXsys
Run it
On your own server, or on iVendNext App Hosting, in its own box and address.
- The retailer
Install with consent
They read what the app will do, agree and install. A new version asks again.
- You
Keep the customer
Your customer, your price, your invoice. Then build the next app.
Want every retailer to find it? Ask us to list it in the App library, with its card and guide page. Build for the App library · What iVendNext builds · Host with CitiXsys or run your own · Publish your app
Building on iVendNext
How do I build on iVendNext?
Start with the simplest of the five ways in that does the job. Request a sandbox site, get the kit from GitHub, make your first call, run a sample, then build: most needs are met by configuration or an outside app.
Can I get a sandbox site?
Yes, if you build for iVendNext retailers, as a partner or as a retailer's own IT team. Request one on this page; we host it for you, with demo stores, tills, staff and customers, and nothing to install. Our team talks to every builder first, then sends your address and logins.
Is there a retail POS API?
Yes. Every record the stores and the back office use is reachable over the REST API, with an event feed of what happens in the stores. Every operation is described in an OpenAPI file in the kit.
Which languages and tools can I use?
Any language your team already uses: Python, JavaScript, Java, C#, Go or PHP, on your own server. Sandboxed functions are written in Rust and compiled to WebAssembly, and your own AI assistant can do much of the work.
How do my apps stay working after an upgrade?
They use only documented, versioned doors, and they add rather than patch. Each version of an extension point, API call or manifest format is served for 12 months after its successor ships.
Do I need to be an iVendNext Partner to build?
No. Any developer can build on the public kit without becoming a partner. Partners also sell, implement and support iVendNext for retailers; talk to our partner team about that.
Start building on iVendNext
Request a sandbox site and make your first call today. Or bring your team to a demo and see the platform you will build on.
Building retail solutions as a business? Talk to our partner team.
