What webhooks are for
A webhook lets you connect NomNom to another system. You give NomNom a web address (a URL) that belongs to you or an integration partner, and NomNom can send an HTTP request to that address. The Webhooks screen in Advanced settings is where you register that address, attach any custom headers your endpoint requires (for example an authentication token), and send a test request to confirm everything is wired up correctly.
This is an advanced, developer-oriented feature. If you are not integrating NomNom with another system, you can safely ignore this screen.
The data NomNom sends
When a reservation event occurs, NomNom sends a POST request to your webhook URL with a JSON body describing the event and the reservation it relates to. A typical packet looks like this:
{
"event": "created",
"timestamp": "2026-07-08T18:30:12.000Z",
"reservation": {
"id": "a1b2c3d4e5f6",
"reference": "NN-4831",
"first_name": "Jane",
"last_name": "Smith",
"mobile": "+447700900123",
"email": "jane.smith@example.com",
"room": "Main Dining Room",
"meal": "Dinner",
"date_time": "2026-07-14T19:00:00.000Z",
"duration": 120,
"adults": 2,
"children": 1,
"status": "confirmed",
"notes": "Window table if possible. One high chair needed.",
"online": true,
"cancelled": false
}
}
Every packet contains a top-level event and timestamp, plus a reservation object with these fields:
id(text) — NomNom's unique identifier for the booking.reference(text) — the human-readable booking reference.first_name/last_name(text) — the guest's name.mobile(text) — the guest's contact number.email(text) — the guest's email address.room(text) — the room the booking is in.meal(text) — the meal or sitting.date_time(text, ISO 8601) — the date and time of the booking.duration(whole number) — the length of the booking, in minutes.adults/children(whole number) — the party size.status(text) — the booking's current status.notes(text) — any notes recorded against the booking.online(true/false) — whether the booking was made through online booking.cancelled(true/false) — whether the booking is cancelled.
Your endpoint should reply with a 2xx status code to acknowledge receipt.
Opening the Webhooks screen
- Open Settings.
- Scroll to the Advanced section.
- Select Webhooks.
The Webhooks screen in Advanced settings.
Setting the webhook URL
In the Webhook URL box, enter the full address that should receive the request, including the protocol. For example:
https://example.com/hooks/nomnom
We strongly recommend an https:// address so the request is encrypted in transit. The address must be reachable from the public internet — a localhost or private-network address will not work. The URL is saved automatically when you finish editing.
Adding custom headers
Many endpoints require extra HTTP headers — most commonly an authentication token or API key. To add one:
- In the Headers section, select Add.
- Enter the header name (for example
Authorization) and its value (for exampleBearer your-token-here). - Select Add to save.
Select any existing header to edit or delete it. You can add as many headers as your endpoint requires. Headers are saved automatically.
Keep secrets safe: treat header values such as tokens and API keys like passwords. Only add them for endpoints you control or trust.
Sending a test request
Once you have entered a URL, select Test Webhook. NomNom sends a POST request to your URL with a Content-Type: application/json header, your custom headers attached, and the following JSON body:
{
"event": "test",
"timestamp": "2026-07-08T12:00:00.000Z",
"data": {
"message": "This is a test webhook from NomNom"
}
}
NomNom then shows the outcome:
- Success — your endpoint replied with a status code in the 2xx range (200–299). The message shows the exact status code returned.
- Failed — your endpoint replied with a status code outside the 2xx range, or could not be reached. The message explains what happened.
The test is the way to confirm that your endpoint is reachable and correctly authenticated before you rely on it.
Troubleshooting the test result
- Status code 200–299 — Success. Your endpoint received the test payload and accepted it.
- 401 / 403 — Your endpoint rejected the request as unauthorised. Check that you have added the correct authentication header (name and value).
- 404 — The address was reached but the path was not found. Double-check the full URL, including the path after the domain.
- 405 — The endpoint does not accept
POSTrequests. Confirm with your integration partner that the endpoint expects a POST. - 500–599 — Your endpoint received the request but errored while processing it. Check the receiving system's own logs.
- Could not be reached / timed out — NomNom could not connect at all. Confirm the URL is spelled correctly, uses the right protocol (usually
https://), is publicly accessible over the internet, and is not blocked by a firewall.
Good to know
- Requests are always sent as
POSTwith the body encoded as JSON (Content-Type: application/json). - The receiving endpoint must be publicly reachable over the internet; internal or
localhostaddresses cannot be tested. - Both the URL and the headers are saved as you edit them — there is no separate save button.