API or webhook?
An API is a door the other system knocks on to ask: give me today’s orders, or add this order. A webhook is the reverse: your system sends a message to an address you choose the moment an event happens, such as a new order, a confirmed payment or a status change. The first suits syncing, reporting and lookups; the second suits instant notification without anyone polling every minute.
Most useful integrations combine both: the webhook tells the delivery software about a new order, and the API lets it ask for the details or update the status.
Connections worth the effort
Start with what is typed twice. Accounting first: the day’s sales, returns and drawer expenses reach the ledger without being rewritten, either through accounting inside the system or a sync with your accounting program. Delivery second: the order goes to the delivery company the moment it is accepted and its status comes back to your screen. Analytics third: orders and customers are read where they live instead of being exported every week. Then your own app, if you have one: it reads the menu and sends orders under the same rules your website works by.
- Accounting and e-invoicing.
- Delivery companies and couriers.
- Analytics tools and dashboards.
- The restaurant’s own app or display screens.
- Marketing tools that need a “new order” or “new customer” event.
What to protect before connecting
The key first: every integration gets its own key with the least access it needs (read-only for an analytics tool, for example), revoked on its own when the contract ends without affecting the others. The key is never sent by email or kept in a shared file, and the system shows its last use so a forgotten key stands out.
Boundaries second: every API request is bound to one business, so an app never sees another business’s data even if it tries. And the number of requests per minute is limited so a broken integration cannot flood your system.
Signatures third: every webhook message carries a signature made with a secret key that your side verifies before believing its content. A message without a valid signature is rejected however correct it looks.
Duplicates and ordering: what both sides must tolerate
Networks fail. An event may arrive twice, late or out of order. So every event carries a unique id and a revision number for the order, letting your side ignore what it already received and know that “status: ready” is newer than “status: preparing” even if it arrived first. Your system resends what was not delivered at increasing intervals and shows you a log of every attempt so you know where the connection stopped.
What suits an integration and what does not
What suits an integration is anything read or recorded under the system’s own rules: orders with prices computed in the system, customers, products, reservations and reports. What does not is bypassing the rules: sending an order with a price from outside the system, confirming a payment without verifying it with the gateway, or deleting financial data. A good integration does what an employee does from the dashboard, with the same permissions, and no more.
Before you sign with an integration partner
Ask for the API documentation and read the sections on authentication, rate limits and available events. Test on a demo business, not on production data. Make sure the key can be revoked from your own dashboard and that the usage log shows you what the other party is doing. And settle from the start who owns the data when the contract ends: orders and customers stay yours, the key is revoked, and that is the end of it.
