What is Omnivore pos?

Omnivore pos empowers restaurant brands to digitize their guest and operational experience in a meaningful and sustainable way. Omnivore software developed by custom mobile app development company provides an end-to-end suite of solutions built on data and insights that help optimize the essential elements of the digital restaurant experience, online ordering, pay at the table, third-party delivery, labor, and analytics. 

Understanding locations

A location is a terminology for an individual restaurant connected to Omnivore pos integration , and it contains data about a restaurant location. Omnivore company is responsible for all activity or data updating tasks of location. Pos integration analyses your needs and requirements and creates useful data such as a menu, modifier, discount, employee details, and order type for your restaurant against a unique location id that belongs to your restaurant. Top mobile app development companies have introduced really helpful restaurant pos integration.

What POS systems does Omnivore integrate with?

Omnivore pos integration integrates with Aloha, Azbar, Brink, Dinerware, Doshii (Impos, Starrtec, H&L, TriniTEQ, ArzPOS), Lavu, Lightspeed, Maitre'D, Oracle Hospitality (3700, Simphony1, Simphony2), POSitouch, Squirrel, Toast, XPIENT plus more in development. Some POS systems support multiple restaurants with a single deployment, like in hotels, airports, casinos, and resorts. In these cases, each individual restaurant is a separate location in Omnivore.

How can the app be integrated with restaurant POS through Omnivore pos?

You can use any backend programming language having suitable web-framework as Omnivore provides API containing resources that have both data for the requested object and links to traverse further into the API. Resources can also include other resources, known as sub-resources. For example, a list of Employees is a sub-resource of a Location. Sub-resources belong to their parent resource.

 Integration and API key

 As we know that Omnivore provides API for almost all types of data regarding restaurant transactions, but to call this API, we need an API key that authenticates each request that came to the pos integration api. As a developer, you need to get this key from your client(restaurant owner) or by logging into the omnivore website by selecting the appropriate location.

Note -  Your account comes with an Application with a Production API Key that you can use to execute calls against the Virtual POS.

Menu and modifiers

Omnivore API contains a menu API that includes raw data that is not presentable to the customer directly. In the real world scenario, restaurant owners often categorize their menu so that it can be easy for customers to choose, but in the case of Omnivore pos, there is no such categorization of menu items. 

Modifiers applied to a menu item, and it can be mandatory for some menu items. The full cost of the modifier in cents, including quantity and all modifiers and discounts. Some pos integration cannot provide a specific cost for ordered modifiers in some scenarios, so this may be null.

We know that Omnivore software provides a universal API, so each object contains lots of unnecessary property with nil or some value that we don't use for our app. This raw data includes lots of objects and their properties, which slows downs and is difficult to parse and process for our app. Also, it is time-consuming as we receive requests from customers having Mobile apps, and then we make API requests to Omnivore, then grab menu data and send back to the customer (mobile app).


Instead of creating API calls for every request made by the customer, It's better to store response data in the backend with only those properties which are needed for our Mobile app. It saves the time required to get a response from omnivore pos integration and makes it easy to parse and process the mapping at the front end.

We know the categorization of menu items is essential to make it easy for customers to find details(price, quantity) of the menu or dish he is searching for. But unfortunately, Omnivore pos doesn't take care of it and provides raw data objects which are difficult for developers to present at the front-end and even difficult for customers to find their favorite item if the menu list is extensive.


Backend developers need to understand that data must be reliable so that at the front-end, we can avoid business logic for the view of the menu and improve app response to the customer. So it's better to store menu items in the backend database with the appropriate mapping of category so that we can save front-end programming efforts by passing category viz sorted menu in response to API, which then improves response time and also customer gets categorized view of the menu helping point of sale integration.

Working with Tickets 

Tickets keep track of the things ordered by customers of a restaurant and are needed to generate virtual receipts for customers at the time of payment.

I.e. {"employee":"100","order_type":"1","revenue_center":"1"}'

Here employee id, order type, and revenue center are mandatory properties and are required to open the new ticket. We have to set a static emp id for the online home delivery orders, and for the restaurant tab(QR code), we can use some logic to change employee id.

i.e., Which table is handled by which employee accordingly, we can grab which employee to assign to open which ticket depending on the tab(QR) of that table.

Omnivore company provides customization in various API, such as opening tickets if we want to set different values for service charges rather than default. This can be achieved by passing an array of service charges with comments.

"menu_item": "MENUITEM ID", 
"quantity": 1, 
"price_level": "PRICELEVELID",
"modifiers": []

I.e., Suppose customers choose a pizza from the menu, and there are three variants of pizza such as large, small, medium, or that restaurant might offer special pricing during certain times of day then should provide options to enable and disable this price level.

Spreedly API  https://core.spreedly.com/v1/receivers/spreedly_omnivore_receiver_token//deliver.json

These are some mandatory things that we need to pass to spreadly as body of API

"delivery" => {
      "payment_method_token" => token,
      "url" => "https://api.omnivore.io/1.0/locations/location-id/tickets/ticket-id/payments/”,
      "headers" => "{{user}}: {{pass}}\nContent-Type: application/json",

 "body" => "{
      "type": "card_type",
      "amount": total-amount,
      "tip": tip for waiter (if any),
      "card_info": {
      "exp_month": month,
      "exp_year": year,
      "cvc2": cvv,
      "number": "card number"   


In response to this API, we received success or errors, if any, to make sure. Whether payment for that ticket is successful or not and we can show appropriate response to the user.

What's a Webhook?

A webhook or web callback or HTTP push API, is a way for an app to provide other applications with real-time information. A webhook delivers data to other applications real-time. Unlike typical APIs, pos integration where you would need to poll for data very frequently to get it real-time. This makes webhooks much more efficient for both providers and consumers. 

Use of webhook in Omnivore pos

There are several events, and transactions executed simultaneously in Omnivore pos integration, and webhook play an important role in this transaction to produce updated data and serve it to restaurants and customers with immediate effect.

Example - 

Assume that we are storing omnivore transactions data on our production server

Let's suppose customer is on the table, and he open's omnivore ticket by scanning QR code available on table and order something from the mobile app and later he asks the waiter to add few more dishes or modifier to his ordered item which then added by restaurants employee from restaurants side then webhook of Omnivore software immediately sent updated order info to the production server to update the data regarding that ticket and is immediately available on customers application.

Let's suppose the customer creates a ticket using the app and forget to close the ticket created by him. After that restaurant employee cancels that ticket due to some reason then webhook of Omnivore automatically gets trigger and sent ticket details to a production server so that server-side business logic will process on ticket data and cancel that ticket from the server as well which helps to maintain the consistency of data between omnivore and production server also helps to send live updates to customer app & to maintain ordered history.


Omnivore pos enables agility in the restaurant industry, and ensures restaurant pos integration be adaptive to the fast changing consumer usage of technology. Our web and mobile app development company have been continuously working towards creating user friendly and dynamic platforms for startups. We would be more than glad to hear about your business plan, and how we can mutually work towards the same.

Do you have any product idea or business need?



Offline mobile app development is critical for users to sync their data properly, when offline. Here, we help you learn the process from implementation to data synchroniz

Omnivore POS integration - Ensuring Agility To Your Restaurant Businesses

Omnivore POS integration - Ensuring Agility To Your Restaurant Businesses

Omnivore software offers a point-of-sales integration API making the restaurant system agile, more customer engaging and adaptive to fast changing business environments.

Unit Testing using Mockk.io

Unit Testing using mockK.io in Kotlin

Learn about unit testing using mockk.io in Kotlin.