Webhooks
Webhooks are an add-on. See What's included, and what's an add-on.
What this is for
A webhook sends a message to a web address you choose whenever something happens in Restodesk.
An order gets paid; Restodesk immediately tells your accounting system, your dashboard, or whatever else needs to know. Nobody exports anything and nothing polls for changes.
It's the simplest way to connect Restodesk to something else, and it's the one to try first.
The events
| Event | Fires when |
|---|---|
| Order Created | A new order is placed. |
| Order Updated | An order changes. |
| Order Cancelled | An order is cancelled. |
| Order Paid | Payment completes. |
| Reservation Received | A booking comes in. |
| Reservation Confirmed | A booking is confirmed. |
| Payment Success | A payment succeeds. |
| Payment Failed | A payment fails. |
| Test Event | You send a test. |
Subscribe a webhook to specific events, or to all events.
Setting one up
Add Webhook, then:
| Field | Notes |
|---|---|
| Name | What it's for — "Accounting sync", "Kitchen dashboard". |
| Target URL | Where to send it. Must accept POST requests. |
| Subscribed Events | Which events, or all. |
Then Send Test before relying on it. That's what the test event exists for.
The target URL is developer work — something has to be listening at the other end. See Connecting apps and devices.
Watching deliveries
Every send is recorded, with:
- The event
- Status — succeeded, failed or pending
- Attempts
- Response code and response
- Duration
- When
Recent Deliveries shows the latest.
Read the failures. A webhook that's been failing for a fortnight is an integration that hasn't worked for a fortnight, and nothing else will tell you.
Replaying
Replay re-sends a delivery.
Useful when the receiving system was down, or a bug at the other end meant an event was received but mishandled. Fix the receiver, then replay what it missed rather than reconstructing it by hand.
Practical advice
- Start with one event. Subscribing to everything on day one produces noise nobody reads.
- Order Paid is usually the useful one. It's the event most systems actually care about.
- Name webhooks by purpose. In a year, "Webhook 2" tells nobody anything.
- Check deliveries weekly while an integration is new, then monthly.
- Have someone own it. Webhooks fail silently from your side — the only sign is a failure count nobody is looking at.
- Don't use them for anything time-critical inside the restaurant. They're for telling other systems, not for making service work.
Security
- Use HTTPS. Webhook payloads contain order and customer data.
- Verify at the receiving end that requests genuinely came from Restodesk. Your developer will know how; a URL that accepts anything is an open door.
- Don't put secrets in the URL.
- Delete webhooks you've stopped using. An abandoned endpoint still receives your data.
Good to know
- Webhooks are per restaurant.
- Which events are available can depend on your plan.
- Failed deliveries retry; the attempt count shows how many times.
- A webhook is not a substitute for the notifications your staff need. Those go to people; webhooks go to systems.