Because your booking diary should not be an island.
Most restaurants we work with run more than one system. There is the booking diary, and then there is the till. Perhaps a loyalty scheme, a rota tool, an accounts package. Each of them holds a piece of the same evening, and none of them talk to each other.
So the same information gets typed twice. Someone reads tonight’s covers off a tablet and keys them into the till. A walk-in gets added at the door and never makes it back into the diary, so the following week’s report is quietly wrong. None of this is dramatic. It is just friction, every single service, forever.
Today we are doing something about it. NomNom now has a public API.
What that actually means
An API is simply a way for one piece of software to ask another piece of software a question, without a human in the middle. Ours lets an approved system ask things like “who is booked in tonight?” or “what has changed since I last checked?” and get a clean, immediate answer.
In practice that means your till can show tonight’s bookings on the terminal, without anyone retyping them. It means a booking amended at four o’clock is right on the till at five. And in time, it means a walk-in added at the door lands back in your diary automatically.
The first release is deliberately modest: reading reservations. Writing them comes next. We would rather do a small thing properly than a large thing approximately.
Who this is for
Mostly, this is for the companies who make the other software in your restaurant — EPOS and till vendors in particular. They are the ones who will build against it, and they are who we designed it around.
You will not need to touch any of it. If your till provider tells you they now support NomNom, it will simply start working. Nothing about the app or your booking page changes.
Free for restaurants. Always.
We want to be plain about this, because the industry has trained everyone to expect otherwise.
Connecting your own systems to your own booking data costs you nothing. Not now, not later, not as an “integrations add-on” that appears on your invoice in eighteen months. Some of the larger booking platforms charge restaurants for the privilege of connecting the till they already own. We think that is the wrong way round.
Your bookings are yours. Getting them into your other systems should not be a paid extra.
A promise to anyone who builds on it
If you are a developer, the thing you actually want to know is whether we will break your integration in six months. So we have written that down and, more importantly, built the guarantee into how we work.
The version is in the address: everything lives under /api/v1/. Within that version we will add things, and we will not remove or change them. No renamed fields, no changed types, no quietly tightened validation. If we ever retire a version, you get at least twelve months’ notice and a direct email — we know EPOS release cycles are slow and often wait on your own customers.
That is not just a good intention. The shape of every response is frozen by automated tests that fail our build the moment anything drifts. It is genuinely easier for us to keep the promise than to break it, which is the only kind of promise worth making.
Built for how restaurants actually work
A couple of details we are quietly pleased with, because they come from paying attention to the trade rather than to software convention.
Times are the venue’s times. A seven o’clock booking is at seven, in your dining room, on your clock. That sounds obvious until you realise how many systems mangle it twice a year when the clocks change. We send the wall-clock time and the time zone separately, so there is nothing to get wrong.
Your status names stay yours. One of our restaurants runs their whole service through the status field — “Checked In”, “Starters”, “Plates Cleared”. That is a lovely way to work and we had no intention of asking them to stop. So alongside your own labels, the API reports a small fixed set of states that other software can rely on. You keep your vocabulary; the till still knows whether the table is occupied.
Have a look
The full reference is at nomnom-app.net/developers.html — and if you are not a developer, it is genuinely fine to never open it. Just point your till provider at it.
The API is in preview while the first integrators build against it, which means we are still listening. If you use a system you would like to see connected, tell us who makes it. Those conversations are how this gets built.
Questions about connecting your restaurant? Just reply — we read everything.