Webhooks & the menu API

Some providers push information to the platform rather than waiting to be asked — a payment result, a delivery status change, a POS menu update, an inbound SMS reply. Each of those needs a callback URL registered in the provider’s own dashboard.

Where the URLs come from

The dashboard shows the exact callback URL for each connection on the integration or payment configuration page itself. Copy it from there rather than constructing one by hand — it carries the identifier that tells the platform which account the callback belongs to.

You register that URL in the provider’s dashboard, not here.

Which providers need one

Provider type	Needs a callback for
Payment gateways	Payment results, refunds, disputes and chargebacks
Delivery networks	Driver assignment, pickup and delivery status
POS systems	Menu changes and order status pushed back
SMS providers	Delivery receipts and inbound replies

A missing webhook secret fails silently

Most providers sign their callbacks, and the platform verifies that signature. If a secret is missing or wrong, callbacks are rejected — which does not look like an error to you, it looks like payments that never confirm, deliveries that never update, or orders that never sync. If a provider “stopped working” without anything changing on your side, check the secret first.

Registering a callback

1. Copy the URL from the integration or payment page.
2. Paste it into the provider’s dashboard, along with any events they ask you to subscribe to.
3. Copy the signing secret the provider generates back into the same integration or payment entry.
4. Trigger a real event — a small test payment, a test delivery — and confirm the platform reflects it.

Rotate a secret and you must update it here in the same session, or every callback from that point is rejected.

The public menu endpoint

There is one read-only public endpoint, for reading an outlet’s live menu:

POST /misc/openApi/getOutletMenu

It returns the same menu your apps show — categories, dishes, prices, availability — so an external site, a digital sign or an aggregator listing can stay in step with what you actually sell, without anyone maintaining a second copy.

Your account manager provides the exact host and the identifiers to send. There is no write API: orders, customers and menu changes go through the apps and the dashboard.

Sensible limits

• Treat callback URLs as configuration, not secrets — but treat signing secrets as secrets, and never paste one into a support ticket.
• Expect duplicates. Providers retry, so the same event can arrive more than once; the platform handles that, and anything you build on top of the menu endpoint should too.
• Poll the menu endpoint politely. A digital sign refreshing every few minutes is fine; one refreshing every second is not.

Troubleshooting

Symptom	Try this
Payments succeed at the gateway but the order never confirms	The payment webhook is not registered, or its secret is wrong
Delivery status never updates	Same, for the delivery network
POS menu changes do not appear	Same, for the POS — then test the connection
It worked and then stopped	A rotated secret that was not updated here
The menu endpoint returns nothing	Confirm the outlet identifier and that the outlet is live

Related: Integrations overview · Messaging providers · Gateway setup · POS integrations