A webhook sends your bookings to another system, such as a till or your own software, as they happen. You give NomNom a web address that belongs to you or your integration partner, and each time a booking is made, changed or cancelled, NomNom posts its details there. If you’re not connecting NomNom to anything, you can leave it alone.
Set it up
1. Open Webhooks. Open Settings and choose Webhooks, under ADVANCED.
2. Enter the address. Under ENDPOINT, type the full address, starting https://, and press Enter (Done on a phone keyboard) to save it. It also saves when you send a test. An http:// address works, but you’ll see a warning, as the details wouldn’t be encrypted.
3. Add headers, if your system needs them. Under HEADERS, click Add, fill in the Name (such as Authorization) and Value (such as Bearer and your token), and click Add. Headers save straight away and go with every request. Use the pencil to edit one or the bin to remove it.
4. Send a test. Click Send test request. The box under the address shows Connected if your system replied with a success code, or Failed with the code it sent back or the reason it couldn’t be reached.
In NomNom Web: Settings → Webhooks. In the phone app: Settings → Webhooks.
When NomNom sends
- created — a new booking, however it was made: by your team, on your booking page or through Google.
- updated — a booking is changed or a cancelled one is restored, or a payment or refund is recorded against it. An online booking that takes a deposit sends created, then updated once the deposit is attached.
- cancelled — a booking is cancelled. This is sent once.
Each one is sent within seconds of the change. It’s attempted once and never retried: if your system is down, replies with an error, or takes more than about 15 seconds to answer, that update isn’t sent again. Every message carries the booking’s full current details, so the next change to that booking brings your system up to date. After an outage, check the bookings for that time in NomNom.
What NomNom sends
Each message is a POST with a JSON body. At the top are event (created, updated or cancelled), timestamp, and a reservation holding:
- id and reference — NomNom’s own id and the booking reference.
- first_name, last_name, mobile, email.
- room and meal — the area and meal names.
- date_time — the booking’s date and time as it shows in your diary. Treat it as your local time, even though it ends in Z.
- duration (minutes), adults, children.
- tables — a list of table names, empty when none are allocated.
- taken_by — the staff name from Taken by, or empty (see Recording who took a booking: Taken by).
- deposit_paid — the running total paid against the booking.
- status — your own status name. Use cancelled (true or false) to tell whether a booking still stands.
- notes — the booking’s Notes. Internal notes are never sent.
- online (true when booked online), created and updated.
Your system should reply with a 2xx code. The test sends event set to test and a short message instead of a booking.
If the test fails
- 401 or 403 → your system refused it. Check the header name and value.
- 404 → check the full address, including everything after the domain.
- 405 → the address doesn’t accept POST. Check with your partner.
- 500 to 599 → your system hit an error. Check its own logs.
- No code, or a timeout → NomNom couldn’t connect. Check the spelling and https://, and that the address can be reached over the internet and isn’t blocked by a firewall.
Good to know
- Table moves are sent too. Swap tables and Optimise tables send updated for every booking they move.
- To stop sending, clear the address and press Enter.
- One address per venue. Each venue you run has its own.
- It carries guests’ details. Names, numbers and emails go to the address, so only use one you or a partner you trust controls, and treat header values like passwords.
- Admins only. Only admins see Webhooks in Settings.