PHP2Shell: Is Your Joomla Site Safe? What to Do Today Introducing Next Boards: Kanban project and task boards for Joomla Next Exams 6.2.0: Exam Studio, six visual question types, exam embeds and six new languages Building the Future of Joomla Extensions
NextSoftware
Next Restaurant — Documentation

Setting up webhooks

Outbound events. When something happens in Next Restaurant, an HTTP POST is sent to the endpoints you configure — so another system can react without polling.

Configure them under Integrations.

Setting up

  1. Enable the API module under Apps.
  2. Go to Integrations.
  3. Add one or more endpoint URLs.
  4. Select which events to send.
  5. Press Generate secret to mint a signing secret, and copy it into your consumer. It is shown once.
  6. Use Test webhook to fire a ping at every endpoint and confirm they receive it.

The webhooks section with configured endpoint URLs, the event multi-select and the test-webhook button

Choosing events

Select only the events you actually consume. Every selected event is delivered to every configured endpoint. Selecting none means all of them, not none. The full list, with each payload, is under Events in this tab.

Delivery log

Integrations shows recent delivery attempts: when, which event, which endpoint, how it responded, whether it was signed and under which schemes, and the delivery ID. It is the first place to look when an integration "didn't get" something — usually the delivery went out and the receiving end rejected it. A run of signed: no rows means the signing secret is empty.

The delivery ID is the same value the consumer saw in webhook-id, so "did you receive this one?" is a question with an answer on both sides.

Choosing endpoints

  • The endpoint must be reachable from your server over HTTP(S). A URL on a private network your Joomla host can't reach will never receive anything.
  • Use HTTPS. Payloads carry order data.
  • Respond quickly. Acknowledge receipt and do the slow work asynchronously; a consumer that takes a long time to reply makes delivery unreliable.
  • There are no retries. One attempt per endpoint, with a five-second timeout. If your endpoint is down, slow, or answers anything outside the 2xx range, that event is gone — it is not queued and it will not be sent again. The attempt is recorded in the delivery log and nothing else happens. Treat webhooks as a fast path, not as a guaranteed ledger, and reconcile from your own records if a gap would matter.
  • Be idempotent. Dedupe on webhook-id (or the body's id, which is the same value). It is stable for one event across every endpoint it is sent to, so a consumer subscribed twice can tell the second copy is not a second event.

Webhooks versus the API

They solve different problems and are usually used together:

Use Reach for
"Tell me when an order is placed" Webhooks
"Give me the current menu" REST API
"Place an order from my kiosk" REST API
"Keep my dashboard in sync" Webhooks to invalidate, API to fetch

Polling the API on a timer to detect new orders is the wrong shape — it is slower, heavier, and misses changes between polls.

Payment webhooks are different

The webhooks described here are outbound, from Next Restaurant to you.

Payment providers also send inbound webhooks — from PayPal to your site — to confirm settlements. Those are configured per gateway, not here. See Payment Gateways.

See also

All Extensions