The Kounta API provides developers an easy way to create and update orders directly on a retailer's point of sale. Seamlessly connecting the online world to brick and mortar stores.
This guide focuses on the high level steps to create orders in varying statuses.
Before progressing we suggest reading the guides below
In this guide we have assumed you have first tackled authenticating and connecting to the Kounta API, and utilising that to retrieve details for the Company and Site you want to create the order at.
You will also need to retrieve the Products, Taxes and Pricelists relative to the Site
Creating an Order
The very first thing to check when sending orders, is to ensure the site is online. You can check this with the check online site endpoint via GET /v1/companies/
Orders can be created in a number of different statuses but the most relevant are SUBMITTED and ON_HOLD
Once created, a SUBMITTED order will appear as a flashing order on the Merchant's POS, alerting them with a chime, ON_HOLD orders will slip quietly into the Open Orders view on the POS without requiring any immediate action.
When the staff open an order in SUBMITTED status it will ask them to either ACCEPT or REJECT the order, moving it into one of those statuses.
Creating an order in a SUBMITTED status is suggested for online ordering and pre-ordering as these tend to require acceptance by the staff in the store in the event they cannot fulfil the order.
Orders created as ON_HOLD are useful when high volume is anticipated or the order requires no input immediately from the staff in the store such as creating a pre-paid tab.
Some useful features to tweak out your desired flow with the Orders endpoint can be found below
- Callbacks allow you to stay up to date on order status changes and action events in your service, we'll notify you of any changes including state changes.
- The ACCEPTED button is required to trigger the production printing, so ensure you use SUBMITTED if you want the order to print in store.
- Modifiers can be applied and negated on lines (eg Soy on a Cappuccino) - Option Sets will be supported soon.
- Specifying a Register ID allows you to control which register in a site gets the SUBMITTED orders. By default a SUBMITTED order is sent to ALL registers in a site which can be a bit obtrusive to the customer experience.
- Price Limits can be set on orders to facilitate pre-paid 'limits' preventing staff from adding more items than the customer has authorised/paid for
- Locks can be used to prevent staff changing certain parts of the order such as Lines and Payments
- Complete When Paid when an order is created with payment and in SUBMITTED status the order can be accepted, but is not actually ready for a customer. You can set these types of orders to require a Ready status, these orders are moved to Pending status when Accepted.
- Updating orders is limited to updating orders you have created yourself, protecting your orders from being edited by other services
- Handling payments processed in your app. If you're using oAuth, under your Add-On configuration in your developer account, set the enable payments setting to true. This will automatically creates a custom payment method, named after your app, when the company grants you access. This can then be used automatically, without specifying a payment method id on your payment data. To remove the need fo you to create, track and include a unique payment method on a per company basis.