Build your own website and app on your POS: the Bill&Go shop API

Most POS systems keep what they know to themselves. The menu, the prices, the day’s sales and the orders sit behind the POS’s own screens, and when your website, your accountant or a delivery partner needs them, somebody types them in again. Prices drift, a sold-out dish stays on the website, and the numbers in the spreadsheet are a day late.

Bill&Go’s shop API is the other way: a door your own systems can use to read from your POS and send orders to it, with a key you make and can switch off in a second. The whole reference is public on this site, so you, or the developer who builds your website, can read exactly what it does before you sign up.

Your own website, taking orders

Build the website your shop deserves, in your own colours, on your own address, with whatever you or your developer like to build with. The shop API gives it everything your POS knows:

• The menu, live. Categories, dishes with their English and Khmer names, prices, photos, options with how many may be chosen, and what is sold out right now. Change a price at the counter and the website shows it.
• Your branches. Each store with its address, map position, phone, opening hours and delivery fee, for a “find us” page or to let the customer choose where to order from.
• Orders straight to the kitchen. The website places the order and marks it paid; it arrives at the POS and prints in the kitchen like any other, with its own call number, and the POS takes it from there.
• Order status. The website can follow each order as it is confirmed, prepared and ready, to tell the customer where it stands.

Your own mobile app

The same works for a mobile app with your shop’s name on the App Store and Google Play: your customers browse your menu, order and pay in your app, and the order lands at your POS. Loyalty, offers and push notifications are yours to design, because the app is yours.

Good to know. An app or a web page never holds the key itself: anyone could take it out of the app. Your app talks to a small server of your own, and that server holds the key and talks to Bill&Go. Your developer will know this pattern; the reference shows what to send.

And everything around the shop

• Sales for your accountant. The daily sales per store, ready for an accounting system or a Google Sheet every morning, without exporting by hand.
• A delivery partner who stays in step. The menu comes from the POS, so the price you change at the counter is the price the partner shows.
• Stock where you need it. The count for each store, for an order sheet for your supplier, or a website that hides what has run out.
• A dashboard of your own. Orders as they change, page by page, to keep another system or a report up to date.

Safe by design

A key is made by the owner in the console, under Settings → API keys, and each one says exactly what it may do:

• Read only, or place orders too. A key for your accountant only reads; the key for your website or app may place orders.
• One branch, or all of them. A key can be pinned to one store, and then it never sees the others.
• Switched off in a second. Revoke a key and it stops working at once; nothing else changes. The console shows when each key was last used.
• Only for the shop API. A key works on the shop API and nowhere else: it can never sign in to the console or change your settings.

Your data stays yours: the API reads it out for you, in plain JSON, whenever you like.

How to start

1. Make sure the shop is on Starter or above: the shop API is one of the connections in the paid plans. Every new shop has a month of Pro to try it.
2. In the console, open Settings → API keys and add a key: name it ("Website"), choose what it may do and which stores.
3. Copy the key. It is shown once, in full; keep it on your server, never in a web page or an app.
4. Send it with every request, as `Authorization: Bearer bg_live_…`, to `https://api.billandgo.app/v1`. Start with `GET /stores` and `GET /menu`.

The shop API reference lists every address, what it answers and every error, with examples to copy.

Tip. Ask any POS you consider to show you its API reference before you buy. If it is not written down, your data is only as reachable as the vendor wants it to be.