Connecting apps and devices
The API is an add-on. See What's included, and what's an add-on.
What this is for
Letting another system talk to Restodesk directly — an accounting package, a loyalty platform, a custom app, a piece of hardware.
This page is for deciding whether you need it. The setup itself is developer work, and this guide hands off to them rather than pretending otherwise.
Do you need it?
Most restaurants don't. Work down this list first:
| What you want | Try this before an integration |
|---|---|
| Numbers for your accountant | Export the reports |
| A one-off data move | Export, or bulk import |
| To be told when something happens | Webhooks — simpler than the API |
| Orders from a delivery platform | Delivery app integrations |
| Your own ordering website | You already have one — see The customer ordering site |
The API earns its place when another system needs to read or write your data continuously, and nothing above covers it.
Honest cases for it
- Accounting — pushing sales and expenses into your accounting package automatically instead of exporting monthly.
- A custom app — something specific to your operation that has to read live order data.
- Group reporting — pulling several branches or brands into one dashboard.
- Hardware — a device that needs order or menu data.
- A loyalty or CRM platform you already run.
Push or pull
Two different mechanisms, and the choice matters:
| Webhooks | API | |
|---|---|---|
| Direction | Restodesk tells you | Your system asks |
| Good for | Reacting to events | Reading data on demand |
| Effort | Lower | Higher |
| Example | "An order was paid" | "Give me last month's sales" |
Start with webhooks. They're simpler, and "tell me when something happens" covers more real integrations than people expect. See Webhooks.
Reach for the API when your system needs to ask questions on its own schedule.
What to give your developer
- Access to the API documentation, which is available in the product where the add-on is enabled.
- API credentials. Treat these like passwords — they can read your business.
- A clear description of what the integration should do. Not "connect to our accounting" but "every night, create an invoice in Xero for the day's sales, split by order type".
- A test environment if you can. Don't develop against live orders.
Questions to ask before you commit
- What exactly moves, in which direction, how often?
- What happens when it fails? Every integration fails sometimes. Who finds out, and how?
- Who maintains it? Restodesk updates; so do the systems at the other end.
- What does it touch? An integration that only reads is far lower risk than one that writes.
- What does it cost to run, not just to build?
An integration nobody owns quietly stops working and takes months to be noticed.
Security
- Credentials are as powerful as a login. Store them properly.
- Give the minimum access needed. Read-only where read-only will do.
- Rotate credentials when a developer or agency stops working with you.
- Keep a list of what's connected. In two years you'll want to know.
Good to know
- The API is an add-on, entitled by your plan — see Your plan and billing.
- API access is separate from staff logins, so an integration doesn't need a person's account.
- Data is scoped to your restaurant, exactly like the app.
- If you're not sure whether something is possible, ask before commissioning it — Getting support.