Build on the same API your restaurant already runs on
RestioX ships a token-authenticated REST API, signed inbound webhooks and a reference that is generated inside every installation. The endpoints your integration calls are the ones the till, the kitchen screen and the staff app call — so there is no second system to keep in step.
1
Base URL and one bearer token behind every call your client makes
9
Documented endpoint sections in the reference your own admin generates
HMAC
Signature checked on every inbound marketplace webhook before a field is read
0
Lines of core code to fork — the API calls the same POS controllers your staff use
One token, one base URL, and the same permissions your staff work under
Authentication is a single POST of a staff account’s credentials, which returns a bearer token. Send that token as an Authorization header on every request afterwards. The token is not a superuser: it inherits the restaurant and branch of the account it was issued for, and its privileges match that account’s roles and permissions exactly. Give an integration its own staff account with a narrow role, and a narrow role is precisely what the API will let it use.
- Tokens are issued per staff account, not one shared key per installation
- Restaurant and branch context travels with the token — no tenant id to pass by hand
- Roles and permissions are enforced on the server, exactly as they are in the admin
- Login is rate-limited to five attempts a minute to blunt credential stuffing
- Read the permissions endpoint to drive your own feature flags instead of guessing
- Switch the active branch on a live token rather than authenticating again
Responses come back as JSON with a consistent status and data envelope, so a client can be written once and pointed at any installation. Errors are HTTP status codes with a message, not a 200 carrying bad news.
# the token comes from a staff account you create
curl "https://your-venue.example/api/application-integration/pos/items" \
-H "Authorization: Bearer $RESTIOX_TOKEN" \
-H "Accept: application/json"
# 200 OK — branch context came from the token
{
"status": true,
"data": {
"items": [
{
"id": 1,
"name": "Espresso",
"price": "3.50"
}
]
}
}Every installation generates its own API documentation page in the admin, written against that installation’s base URL and shown in the languages you have enabled. A super admin can mint a read-only public link so an outside developer can read it without an account, and revoke that link the moment the work is finished. We will also send the reference on request, before you commit to a build.
The surface, group by group
These are the families of endpoints in the reference. The exact paths, parameters and response shapes are documented per endpoint inside your admin — we would rather you read them there than trust a marketing page that has drifted.
- Platform and configBootstrap a client: restaurant, branch, enabled modules, locales, currencies, receipt settings and the printers a ticket can route to.
- Menu and catalogueMenus, categories, items, variations and modifier groups, priced the way the till prices them.
- Orders and paymentsCreate an order, update it, move its status, add a tip, take split payments and settle it.
- KOTs and kitchenRaise a kitchen ticket for an order, list its tickets, move ticket and line statuses, read KOT places and cancel reasons.
- Tables and reservationsTable state with a force-unlock for a till someone walked away from, today’s covers, and creating or re-statusing a booking.
- Customers and staffLook up and save customers and their addresses; list waiters, delivery executives, roles and staff.
- Cash registerRegisters, sessions with open, close and summary, cash in, cash out, safe drops and note denominations.
- DeliveryDelivery settings, fee tiers and fee calculation, platforms, assignment to a rider and delivery status.
- NotificationsRegister a device token, list stored notifications, mark one read and fire a test push.
- Multi-POSRegister a third-party POS device and check its status, so another till can work alongside RestioX.
Events arrive signed, deduplicated and answered in milliseconds
RestioX receives webhooks as well as serving requests. Each connected delivery marketplace gets its own endpoint carrying its own secret, and every call is checked against that platform’s HMAC signature before a single field is read. A verified event is stamped with the provider’s own event id, so a retry that arrives twice is recognised and dropped rather than turning into a second order on the pass.
- A separate URL and secret per platform — rotate one without touching the others
- The signature is verified by that platform’s adapter, before the payload is parsed
- Duplicate provider event ids are dropped, so a retry cannot double-book an order
- The endpoint answers 200 immediately and hands the work to a queue, never inline
- WhatsApp message-status callbacks run on the same principle, including Meta’s verification handshake
Unrecognised and unsigned calls are logged and answered 200 as well. A rejected event should not teach a stranger which of their guesses was almost right, and a platform that keeps retrying a bad credential helps nobody.
From nothing to a live integration
-
Step 1
Create an account for the integration
In the admin, add a staff account for your integration and give it a role carrying only the permissions the job needs. That account is the identity every API call is attributed to, which turns machine traffic into an audit trail rather than an anonymous key nobody can place.
-
Step 2
Exchange the credentials for a token
POST those credentials to the login endpoint and take the bearer token from the response. Keep it as a secret on your side and send it as an Authorization header on every request. The login route is deliberately rate-limited, so hold the token rather than signing in once per call.
-
Step 3
Open the reference in your own admin
The Rest API documentation page is generated against your base URL, in your language, with a worked request and response for each endpoint. If an outside developer is doing the build, generate the read-only public link for them and revoke it when they hand over.
-
Step 4
Call the endpoints
Bootstrap with the config and permissions endpoints, then work whichever group you need. Because the API is a proxy over the same controllers the on-screen POS uses, an order created over HTTP behaves like one rung up at the counter — it prints, it moves stock, it lands in the same reports.
-
Step 5
Receive what comes back
Point a connected marketplace at its signed webhook URL and register device tokens for push. From there traffic runs both ways: you call RestioX for state, and RestioX calls you when something changes on a platform you do not control.
Run RestioX under your own name
If you sell, host or build restaurant systems for a living, RestioX is built to sit underneath your brand rather than beside it. One installation serves many restaurants, each with its own branches, staff, menus, stock and money, and the branch scope is enforced in the data layer rather than screen by screen — so a tenant has no view that quietly leaks a neighbour’s takings.
A subdomain for every venue
Each restaurant on the installation resolves at its own subdomain, and the storefront a guest opens is that restaurant’s — its menu, its branding, its ordering rules. The subdomain module also keeps a blocked-names list, so reserved words stay yours.
Many tenants, one platform
Add restaurants and branches under a single deployment, with staff, roles, menus, pricing, reports and takings kept apart per tenant. Run one estate or a hundred without standing up a separate install for each of them.
A module system, not a monolith
POS, kitchen, inventory, loyalty, kiosk, cash register, WhatsApp, AI, backup and the REST API itself ship as modules. Switch on the ones an account has paid for and leave the rest off, per installation.
There is no self-serve reseller checkout, and we would be doing you a disservice to pretend otherwise. White-label scope, hosting, support tiers and commercial terms are agreed case by case, so the quickest route is a conversation — tell us the size of the estate, the brand you want on it and the stack it has to live inside.
Partner with RestioX
Send us the shape of your business and we will come back with what a white-label, multi-tenant RestioX looks like for it.
Three things the API is asked for most
A companion app you own
Build a mobile or web client on the endpoints RestioX apps already use — a driver app in your own livery, a dashboard for one estate’s area managers, a members’ club screen that nobody else on the platform sees.
A stack that already exists
Push orders and takings into the accounting, rota, BI or CRM tool a group already runs on, instead of asking a hundred managers to key the same numbers in twice every Monday morning.
A second till alongside ours
Register a third-party POS device through the multi-POS endpoint and let it work next to RestioX — useful when a venue is mid-migration, or has hardware it is not ready to retire yet.
The questions we get before a build starts
There is no separate API key to buy. You create a staff account for the integration in the admin, POST its credentials to the login endpoint, and receive a bearer token in the response. Send that token as an Authorization: Bearer header on every request. Because the token belongs to a staff account, you decide what it can reach by choosing that account’s role — an integration that only reads the menu never needs the permission to refund a card.
No. Restaurant and branch context is attached to the token itself and enforced on the server, not passed as a parameter your client could edit. If a token needs to work across several branches of the same restaurant, you switch the active branch with a request on the live token rather than sending a branch id you chose yourself.
Inside the product. Every installation generates its own documentation page in the admin, written against that installation’s base URL and available in the languages you have enabled, with a worked request and response for each endpoint. A super admin can generate a read-only public link so an external developer can read it without an account, and revoke that link afterwards. Ask us and we will send the same reference before you commit to a build.
It is dropped. Every inbound marketplace event is verified against that platform’s HMAC signature and then checked against the provider’s own event id, which is unique per platform, so a retry cannot become a second order. The endpoint answers 200 straight away and processes the payload on a queue — which is also why a heaving Friday service never turns into a webhook timeout on the platform’s side.
The login endpoint is limited to five requests a minute, because that is where credential stuffing would show up; hold the token you are given rather than signing in per call. Inbound marketplace webhooks are throttled as well. Limits across the rest of the surface depend on how your installation is hosted, so if you are planning something high-volume, tell us the shape of the traffic and we will size it with you instead of guessing in a footnote.
Yes, by conversation rather than by checkout. The platform is already multi-tenant, restaurants already get their own subdomains, and features ship as modules you can enable per account, so the technical groundwork is in place. Branding scope, hosting, support and commercial terms are agreed case by case — contact us with the estate you have in mind and we will put a proposal against it.
Get a token and read the reference
Open an account, add a staff user for your integration, and the API documentation for your own installation is one page away — base URL, worked examples and all. If you would rather see it before signing up, ask and we will send it over.
Start Free Trial