Node.js REST API with OpenAPI docs, for developers and CTOs.
You describe your resources and their rules; the AI writes the collections and routes on a foundation that already has accounts, Dev and Prod, hosting and HTTPS. The OpenAPI 3.0 spec exports as soon as the front end or the mobile team asks for it, and every request can be traced in the Workshop down to the collection it writes.
Updated on
Demo: Comptoir Bio, a fictional chain of twelve organic grocers in Lyon, whose API and click & collect site are built with Kubbler.
The front end, section by section
Comptoir Bio's home page in render order: Home rail, Process steps grid, Story split, each section with its block and its identifier.
Fields instead of values
On the canvas, a block bound to the API shows its expressions rather than data: the hero button waits for the name of the chosen shop.
orderFlow and its routes
The orderFlow block, linked to the listStores and listSlots routes, then to the stores, stocks and orders collections. createOrder, setOrderStatus and productStock sit further down the routes column.
Croix-Rousse stock, live
The site reads the same API as the mobile app: 56 products on the shelf, 6 out of stock, next pickup Monday at 10 am.
Comptoir Bio, a demo built with Kubbler.
Comptoir Bio runs twelve organic grocers in Lyon and its suburbs, and its click & collect mobile app had no proper API. This one serves the catalogue, each shop's stock and the orders; the pickup site is built on top of it.
12 shops, 62 October products, one stock level per product per shop
stores, products and orders controllers, responses declared field by field for the OpenAPI 3.0 export
Pickup every 30 minutes, 10 am to 7.30 pm; unpaid, the stock goes back on the shelf after 30 minutes
The twelve shops, their customers and their stock are made up, and so is the chain; payment runs on Stripe in test mode.
The whole site, page by page
Each thumbnail is a complete page of the demo, as a visitor sees it. On a computer, hover one to scroll through it.
A basket at Croix-Rousse, from the stock on screen to the 409.
For each thing the user does, what you read in Kubbler at the same moment: the route called, the rule applied, the row written.
Their own shop's shelves
Croix-Rousse is selected: 56 products on the shelf, 6 out of stock. Switching shops switches the stock shown, served by the same route the mobile app calls.
Where each value on screen comes from
The Workshop opens on the home page, with its tree alongside. On the canvas, blocks bound to the API show their fields, so you know which section depends on which route before touching any code.
The last bag of chestnuts
Five products, €23.25, pickup today at 5.30 pm. On the Ardèche chestnuts, the basket warns that the whole shelf is already in it: 1 in stock.
The POST, before it writes
In Mechanisms, orderFlow and the routes it calls. On submit, createOrder only takes a quantity if the shop still has enough, in a single operation: two customers cannot leave with the same last bag.
Someone else got there first
At checkout, the chestnuts are stamped "Rupture ici", out of stock here. Nothing is charged; the message points to Monplaisir (23) and Part-Dieu (22), which still have some.
The order, row by row on Dev
In orders: shop, customer, items, slot, total, payment status, whether the stock was released. You filter with conditions or in Mongo JSON; on Prod, the table opens with no way to write.
Screenshots: Comptoir Bio's site for the Croix-Rousse shop, and the comptoirbio project in the Workshop, Dev environment.
Saturday at Croix-Rousse: 17 paid orders, and no bag sold twice.
Every order here went through POST /orders, which takes stock from the shop in the same operation that checks it. Once the last bag of chestnuts was gone, the next basket got a 409 outOfStock naming the product, the stock left and the shops that still have it, and nothing from that refusal reaches the preparation screen. The mobile team picks up these routes described in OpenAPI 3.0.
Saturday's count
Top right: 8 orders to prepare, 3 ready, 6 collected, so 17 paid orders worth €301.58.
One slot, its bags
At 10 am, Mathilde Garnier and Karim Benali, 4 items each, already collected. An unpaid order never shows up here.
The shop, as tabs
The twelve shops head the list; each team opens its own and moves orders along through the setOrderStatus route, open to administrators only.
The foundation under every project, your code on top.
Accounts and infrastructure are identical from one project to the next, and you don't maintain them. The data model, the routes and their rules are decided and reviewed on your side.
Our part
The code you rewrote on every previous project, already in place in this one.
Full authentication
Sign-up, email verification, sign-in, password reset and two-factor authentication, routes and screens included. The plan marks them as included: the AI never regenerates them.
Dev, Prod and hosting
Two environments, each with the project's own database. OVHcloud in France, HTTPS, automatic backups: no deployment pipeline to write.
Cookies and legal pages
A banner that refuses everything by default, plus a legal notice and a privacy policy drafted from the publisher's details, to have reviewed.
Your part
What sets your product apart, readable in the Workshop and editable by hand.
The data model
Collections, fields, types, required fields, relations: decided in the plan, then changed in the data editor, with a versioned schema.
Routes and scheduled jobs
A custom route or a scheduled job is written by hand and tried in the API sandbox. Every saved file is checked before it is accepted.
The OpenAPI spec
Exported at any time as OpenAPI 3.0, a Swagger page or a Postman collection, for the front end, the mobile app or the partner integrating your API.
Week three of the project, and not one business route yet.
The rule that makes the product often fits on one line: a room cannot be booked twice for the same slot, a quote expires after thirty days. Before you can write it, you need sign-up and email verification, password reset, two-factor authentication, one database for Dev and one for Prod, a deployment, a certificate, then the documentation the mobile team is waiting on. The same work as on the last project, written once more, and only noticed the day it breaks.
Every usual shortcut has a price. A Next.js or Express boilerplate gets you going fast, then drifts from its template in the first week, and its security fixes have to be ported by hand. A backend-as-a-service gives you accounts and a database in an afternoon, but the business logic ends up scattered across access rules, functions and client code, and the docs are still yours to write. A low-code platform is faster still, until the day you have to say exactly which route writes to which table. An AI code generator hands every project its own authentication, to be reviewed line by line.
In Kubbler, accounts, environments, hosting and consent come from a foundation shared by every project, maintained by our team, which you can see but not change. Your project starts at the business rule: the AI writes collections, routes and background tasks on Node.js and MongoDB, and the front end in Next.js. You review every link in the Workshop, write by hand the routes that need it, and export the OpenAPI 3.0 spec at any time from the project's configuration.
What it costs
One project and 500 sparks a month, the budget that pays for AI generations. Packs can be added if you need more.
With your own domain: €44 excl. VAT a month.
No commitment. The domain name itself is paid separately.
See all pricesWhat to have ready
The rules that are not up for discussion: what the API must refuse, and when.
Your resources and their fields, even as a plain list.
An existing spec, if you have one: OpenAPI 3.0, Swagger 2.0 or a Postman collection can be imported.
Your third-party service keys, for the Env tab.
The project's domain name, if you already have one.
Nothing else: no specification, no mock-up.
The questions we get asked.
Including the ones where the answer is "not yet".
Node.js and Express on MongoDB on the server, Next.js and React on the front end. Routes are declared in JSON configuration, controllers and modules are written in JavaScript, and each project has its own database.
You write it in the project's code editor and try it in the API sandbox. On save, every file is checked before it is accepted, a security review reads the change (it is counted in sparks), then it joins the project history, readable as a diff next to the AI's changes.
Not yet. The foundation stays with us and there is no repository to connect. The API description, on the other hand, exports whenever you want as OpenAPI 3.0, Swagger or Postman. Your data is yours: at the end of the contract, the DPA provides for its return or deletion.
No. The foundation is shared by every project and shows up read-only in the Workshop, under the name Kubbler services: you see what your project borrows from it, without being able to change it. If your product needs a behaviour the foundation lacks, write to us.
Two roles, administrator and user, and each route is either public or requires sign-in. No finer roles or per-resource permissions for now. In Kubbler, each member of your team is a viewer, editor or administrator, and only administrators push to production.
The Starter plan is €29 excl. VAT per month, plus hosting: €5 excl. VAT per month with a kubbler.app address, €15 excl. VAT per month with your own domain. No commitment. The plan includes one project and a monthly budget of sparks for AI generations.
Start with the rule you've been putting off for three weeks.
In the Studio, describe your resources and what must be refused. Kubbler proposes a plan, you approve it, then you trace a request in the Workshop and open the spec in Postman.