Tanda and Doshii Making Better Staffing Decisions At Venues POS

Tanda is a cloud-based global workforce success software. The platform offers strong payroll and rostering features, as well as powerful real-time insights that help businesses track the connection between sales and their human capital.

Tanda user using screen in app doshii api

Tanda believes that organisations are successful when their workforce is successful

Tanda lets venues on-board employees, build shift rosters in minutes, automatically calculate pay based on the hospitality award and employees are able to clock in via the Tanda time clock app.

This is particularly valuable in the hospitality industry, as operational management and staff can compare expected to actual figures as the day progresses – allowing them to make on-the-spot adjustments as needed and ensuring they are able to make better data-driven decisions

Tanda relieves the administrative burden by helping venues:

  • Stay in control of staff rostering and shift swapping as the Tanda mobile App puts rosters, notifications, leave management, and the ability to cover shifts in the hands of employees.
  • Ensure regulatory compliance with Hospitality award rates as well as automating their wage calculations, including base rates, overtime, allowances, and higher duties
  • Manage and predict staff count based on-demand data

Bringing the venue all the data it needs to effectively manage teams on an easy to navigate platform with Tanda.

Doshii GM, Greg Williams, explains, “Having live data allows customers to control their business and fine-tune their operation as the day unfolds, instead of having to try and correct events after the fact when it’s too late to remedy.”

Connecting directly into a venues single source of truth, the point of sale system (POS) and Tanda. The Doshii API is used to connect the Tanda platform with the venues POS ensuring that the data is allied and accurate in real-time, seamlessly.

Tanda Live Insights

Dan Etiel, Tanda CMO says “By connecting Tanda and Doshii, customers get real-time sales data which allows them to optimise their business operations live throughout the day by making data-driven decisions. This level of insight has not been available before and is a significant step forward for real-time business intelligence.”

Measure the metrics that matter

Tanda further offers a customisable on-boarding process for venues and a one-touch intelligent rostering with 5-point compliance check. A convenient mobile solution for employees to view rosters, apply for leave and offer to fill vacant shifts. The App can send automated reminders to staff for their next shift and offers optimised time and attendance with facial detection, for easy clocking in.

Doshii Tanda Shift PlannerTanda Screen Clock Out Doshii APITanda POS Team shifts Doshii

The handy Scheduling App sends notifications the manager on shift when staff are late, working beyond their roster, going into unexpected overtime, not taking a required break or are absent. Operational compliance is ensured as Tanda offers Award interpretation for over 35 industry awards and the ability to build in EBA’s on request.

Become compliant with ease – pay wages correctly every time with Tanda

Wages and payroll are simplified and Tanda offers payroll integrations with all top payroll solutions and offers a secure 2-way sync.


Tanda  offers a FREE 14 day trial – sign up your venue here

Doshii Every critical business app you need to run your hospitality venue – check out our integrated apps.



Mr Yum partners with Doshii to seamlessly connect to POS systems

Mr Yum, an innovative startup that allows customers to see a visual version of a venue’s menu on their phone by simply hovering their camera over a QR code, has recently partnered with Doshii to seamlessly connect to POS systems.

Imagine Instagram for the restaurant menu but better! Most menus don’t bring a flutter to your heart but with Mr Yum dishes are brought to life.

Mr Yum solves the age-old problem of deciding what to order at a venue by showcasing beautiful photos of every dish and allowing users to filter menus by categories like vegetarian, vegan and gluten-free. They can even see the whole menu translated into 5 other languages including Mandarin and delve deeper into dishes by reading the ingredient definitions. No more feeling silly asking what ‘labneh’ is!

Even better, the online visual menu offering is completely free for venues.

Mr Yum also offers a mobile order and payment portal that uses Doshii to connect seamlessly to a venue’s POS system, allowing the customer to order straight from their phone.

Australian Venue Co, who has recently gone live with the Mr Yum-Doshii integration at the Winter Village in Melbourne’s Federation Square, encourages venues to adopt these beautiful mobile menus. Kelsi from Australian Venue Co had the following to say “Orders from consumers own devices are quickly processed by allowing our customers to scan a QR code and be redirected to a web-ordering page, complete with images of all the items that we sell. Once the order is complete and payment is made the order is sent directly to our POS system via Doshii and prints out at the relevant areas, reducing cost and resulting in faster orders.

Watch the video below to see Mr Yum in action Winter Village in Melbourne.

Mr Yum at Melbourne's Winter Village

Want to have your own little slice of a winter wonderland down under? ? ??Now you can! ?The Winter Village is a euro-style slice of winter wonderland at Fed Square – complete with an ice skating rink, cosy igloo village and menu of specialty winter foods you can order easily though Mr Yum on your phone, with no app required! ??Mr Yum mobile web ordering means no standing in line in the cold! Order on your phone from anywhere at the event and you’ll receive a text message when your food is ready to collect! ? ? ?Follow Haley on her night out there to see the magic for yourself. ?????

Posted by Mr Yum on Friday, 14 June 2019

Kim Teo, co-founder of Mr Yum has said that “the benefit of using Mr Yum is that users buy more on digital platforms using visual persuasion. The diner is happier as they have had a better experience at the venue, more information and quicker service.”

Using Mr Yum is easy as pie – the user simply scans the unique QR to see photos of each dish with descriptions and pricing. Then with the click of a button, items can be added to cart and payment processed via one-touch Apple or Google Pay. The order is then placed via the venue’s POS system – thanks to Doshii.

Do you want to connect your venue to Mr Yum via Doshii? Register your interest here.

What’s New at Doshii: July 2019

We’re excited to share some great updates about the Doshii platform, highlight some new POS connected Apps and a new member of the Doshii team.

Stay up-to-date with our latest updates via Linkedin, Facebook and Twitter.

Doshii July 2019 Update About Doshii for Venues

Learn more about how Doshii helps your venue with the best hospitality Apps all in one place.

New App Store: Making it easier to find great Apps to drive your hospitality business forward

Here at Doshii we have been sharpening our focus toward attracting even more top-notch Apps and making it easier for you to find and connect the Apps that matter to your business.

To that end, we’ve launched the revamped Doshii App Store. 

If you don’t see an App you need for your business Drop us a line and let us know.

Visit the Doshii App Store

App Spotlight: Cooking the Books teams up with Doshii to make kitchen management even more streamlined and profitable for venues

We’re excited to announce that Cooking the Books, a complete kitchen management tool, has recently teamed up with Doshii to make kitchen management for venues even more streamlined and profitable!

Cooking the Books offers a range of solutions to help increase the profitability of hospitality establishments and has designed a range of software programs to give hospitality venues the financial control and consistency they want. This web-based computer program has been designed to generate information to venues in relation to food costs, stock control, purchase orders, invoicing recipe cards, recipe cost sheets, electronic ordering and receiving, tendering, and menu and function costing.

By integrating with Doshii, venues using Cooking the Books are able to link information from their kitchen management tool directly to their Point of Sale systems.

Andrew Briese, CEO, Cooking the Books Group of companies believes that the integration between Doshii and Cooking the Books “is a huge benefit to our Hospitality customers.  Cooking the Books interface with Doshii allows all the pricing of menu items and modifiers to be captured in real-time in the venues Cooking the Books platform.  All sales information from the POS is visible and as soon as the sale is made the stock is decremented so that real-time stock movements and Gross Profit margins are available.”

Via the Doshii integration, all transactional data feed in real-time through to Cooking the Books, ensuring that venue management have real-time visibility of their stock based on sales directly from their POS.  Doshii also allows for live menu, item and modifier pricing directly via the venues Point of Sale system.

Get Connected with Cooking the Books

App Spotlight: PosPay drives customer engagement

Doshii is pleased to announce that mobile customer engagement and payment platform, PosPay, is using Doshii to provide an enhanced customer experience for large hospitality operations.

PosPay delivers seamless, location-based ordering for customers at restaurants, hotels and festivals by customising their personal preferences when they are in range of a venue. Once in-venue, PosPay allows customers to enjoy meals and entertainment hassle-free, with payments transacted quickly and easily on their mobile phone.

The Doshii-PosPay integration provides a seamless experience for venues too. Staff receive orders directly through PosPay, reducing multiple order-handling and minimising the amount of training required for new staff members. This eliminates costly misplaced orders and frees up staff for more productive value-added customer interactions.

Read more about this integration.

Get Connected with PosPay

Doshii Welcomes Silicon Valley Entrepreneur As Advisor

Doshii is pleased to welcome the former Head of Product across the Uber Developer Platform, Chris Saad, as a strategic advisor to the team. Chris is lending his vast experience and skills to further develop the Doshii platform and Doshii App Store to make it easier than ever for venues to connect Apps to their POS.

With his help, we intend to rapidly expand our offering of rich Apps for your hospitality business over the months and years ahead.

Read more about this key appointment.

Everything about API Integration

Doshii CTO, John Twomey, has been working on a blog series covering all aspects of API Integration.  The first articles of the series have been released. For more on this series make sure to follow us on Facebook, LinkedIn, and Twitter, or sign up for our newsletter.


What is API Integration

API Integration Basics

Architecting Multiple integrations via one API

App Integration Challenges

POS Integration Challenges

API Integration Best Practices

Data Modeling Best Practices

Business Logic Best Practices

API Integration Maintenance

API Integration Real-Time Communication

Feeling Stuck?

API Integration Security…coming soon

Integration Monitoring…coming soon




What is API Integration

Application Programming Interfaces (API’s) provide a documented pathway for accessing the features and functionality of third-party systems through a (typically) stable and controlled interface. By leveraging API’s effectively, a developer can quickly and easily integrate with or expand upon a preexisting external system.


API Integration Background

Prior to the widespread adoption of web-hosted REST/HTTP API’s, service-oriented architectures, and other supporting aspects, integrating with a third-party solution could be a mammoth undertaking. In the worst-case scenario, it could mean attempting to reverse-engineer a way to communicate with the system using disassemblers, packet sniffers, and similar tools. Often this would mean dealing directly with the solution’s inner workings, with no guarantees that its core business rules would be enforced should a developers’ code accidentally break them. Often the next update to the software being integrated with would break some or all of the integration, requiring hasty and sometimes extensive revisions.


Such is the developer’s world in the absence of a published API. And such is the importance of having, and being able to effectively use an API. What an API brings to the table is an officially supported, documented, (hopefully) stable, and (hopefully) safe roadmap for integrating with an external system. APIs provide access to a service through a consistent interface, regardless of the technology being adopted by the client


In our case, we at Doshii have a common interface into all of our POS, regardless of their underlying technologies, allowing Apps a re-usable communications layer to interface with POS systems.


Gone are the disassemblers and the packet sniffers, and the need for the developer to worry about any of the system’s business logic, security constraints, or other internal machinations. If the API is well-managed (not every API is), breaking changes should be a rare occurrence that comes only after plenty of warning. In essence, an API frees a developer to focus purely on their own solution and allows them to talk with external systems in a safe, secure, and maintainable way.

Modern Era

The importance of being able to understand and work with third-party API’s had only increased as technology has trended towards a more cloud-based, SaaS-oriented model. Even with small projects, giving users the option to authenticate using their Facebook, Google, or Twitter account is nearly a de rigueur requirement these days, with far deeper integrations hardly uncommon. And with a huge budget and a large team of world-class hackers maybe you could find your own way into the massive and extremely complicated systems operated by these top-tier technology companies. But why would you bother, when every one of these companies provides a public API supporting authentication (amongst a myriad of other things)? The only answer is that you wouldn’t, and it would be crazy to even try.


Instead, you would check the published API’s, and quickly discover that all three companies have authentication API’s standardized around something called OAuth2. And you would integrate using that, confident that your integration will be secure, stable, and maybe even flexible enough to accommodate any other OAuth2 provider out there. And after that, the sky’s the limit. Want to integrate with Slack? There’s an API for that. Or maybe Jira? There’s an API for that as well. Or maybe you just want to sell some stuff from Amazon or stream some cool music. All of that can be accomplished, and in every case, it’s accomplished by using a published webservice API. So, as we move into the modern era of distributed, cloud-based solutions, the answer to almost any question is “there’s an API for that”. Being able to navigate, understand, and leverage those API’s effectively is key.


With Doshii this means that:

  • No matter how many businesses you connect with through Doshii, you only need to maintain one integration
  • You can be sure of a stable Interface where any changes will be announced in advance and backward compatibility is of paramount importance
  • Detailed documentation of an existing standardised connection
  • Simplified process for development and integration
  • An experienced API Development team available for support, consultation, and implementation
  • Allow your development team to focus on product development rather than integration and maintenance
  • You have confidence in a trusted, secure connection
  • And a Dashboard to monitor all your integrations and help troubleshoot issues

Get Started With Doshii


Back to Top


API Integration Basics

APIs can come in all shapes and sizes. However, most successful APIs follow similar patterns in terms of structure, security, data formats, and protocols. Understanding these key aspects can be the difference between a successful API integration and hours of frustration.


Features of an API Integration

While there exists a nearly endless series of options with respect to how to create an API Integration, most webservice APIs will be defined by a handful of key features.



Most typically, a webservice API will be accessible over HTTP. This isn’t a given as technically anything accessible over the Internet may be classed as a “webservice”, however it’s generally a safe assumption. Webservice APIs that use any other strategy are quite rare, outside of the embedded-device space.

Slightly more common is layering a higher-lever protocol on top of HTTP, such as SOAP. While once quite common and still quite relevant in the .Net sphere, this strategy has been gradually losing ground to smaller and lighter APIs that run directly over HTTP



The most common approach to structuring a HTTP-based webservice API is called the RESTful paradigm. A significant topic in and of itself, in essence, this approach means that different HTTP Verbs are used to perform different operations. For instance, you might need to use a ‘POST’ request to create something, a ‘PUT’ request to the same URL/endpoint to update it, and a ‘DELETE’ request (again to the same URL) to delete it.

How closely a wbservice follows this approach varies widely. Some keep it formal and expect the integrator to be fluent with their ‘PUTS’ and ‘POSTS’, ‘GETS’ and ‘DELETES’. Others may take a more middle-ground approach and follow a simplified “use ‘GET’ to read, and ‘POST’ to write” pattern. Others may be more laissez-faire about it and take an “all (or most) operations can be performed using both ‘GET’ and ‘POST'”, leaving the integrator free to do whatever is more convenient on their end.

Generally, any pattern is fine, so long as there is one. A quality API will not stipulate arbitrary REST-related requirements with no discernable rhyme or reason.


Response Format

Although APIs have used (and will continue using) a variety of data formats, with public webservice APIs XML and JSON are the dominant players by a wide margin. Although XML was established first and adopted into pretty much everything back in its heyday, it has been rapidly losing ground to the lighter-weight and more human-readable JSON.

Many APIs will allow an integrator to choose whether they want to receive their response in XML or JSON. Where only one format or the other is offered, it’s often possible to judge the age of an API by the data format it returns; XML tends to be preferred by older webservice APIs, and JSON is more common in newer APIs. Some high-level protocols, such as SOAP, may essentially dictate that one format or another be used.

In general, however, if you’re comfortable working with XML and JSON you’ll have no problems talking with most published webservice APIs.



For a modern webservice API integration SSL is the de facto minimum standard when it comes to security. Some APIs may layer additional security on top of this, such as request signing and other cryptographic techniques to verify the origin of the request and guarantee that its contents haven’t been tampered with. For instance, Amazon operates all of their APIs over HTTPS and in addition to that requires API consumers to implement a fairly involved request-signing algorithm.

As a general rule, however, SSL is “secure enough” for an API integration and represents the common starting-point for most webservice APIs. Requiring additional security over and above what SSL offers is somewhat rare, and often costs more in frustration than what it gains in added security.

While increasingly uncommon, it’s not unheard of for a webservice API to operate over plain HTTP with no encryption or other forms of security. This may be okay, but only if the API is neither receiving nor transmitting any personal user data or other sensitive information (including API access/secret keys!). If the API contains any sensitive information, you should not use HTTP!


Other Important Bits

While not part of the API itself, documentation is also of critical importance to an integrator. In the absence of documentation, connecting to an API is all but impossible. Without quality, consistent, up-to-date documentation the task can easily become a frustrating exercise in trial-and-error.

High quality documentation that uses consistent, intuitive terminology to explain concepts and important aspects of an API can be a critical factor in a successful integration. In the event you’re attempting an API integration and you discover that important API documentation is incomprehensible, inaccurate, outdated, or just plain missing, it’s a wonderful opportunity to take a step back and see if maybe there’s an alternative API available that can be used to accomplish the same task.

That’s why here at Doshii, we’ve created a detailed API integration documentation hub, which we constantly keep updated with guides for integrating with our platform. Check it out here


Putting it Together

Success as an integrator depends upon having a good understanding of the defining features of a modern webservice API. A solid knowledge of these basics will help when assessing the relative strengths and weaknesses of different APIs, so that the best candidate can be chosen and wasted time and frustration can be avoided. Combined with quality documentation this should help you quickly develop a clear understanding of

the API and identify any gaps between your own system and the API as early as possible so that any potential issues can be planned for and addressed.

To learn more about integrating with Doshii and to speak with our technical team, get in touch through our contact page.

Get in Touch

Back to Top

Architecting Multiple integrations via one API


The complexities of integrating with third-party API’s can quickly multiply due to the rapid proliferation of competing API’s and standards. This significantly increases development, testing, and maintenance time/costs, but can be mitigated against by integrating with a ‘middleware’ API that delegates to various third-party services.


The Proliferation Problem

While the rapid growth and adoption of webservice API’s and standards have been a real boon for the software industry, nothing comes without a cost. The cost, in this case, is a rapidly expanding and constantly evolving frontier in which there are often multiple offerings in any given domain, several of which often proving desirable candidates for integration.


As we saw in the previous articles What is API Integration, and
API Integration Basics, the answer to “How do I do X or integrate with Y?” is almost always “There’s an API for that”. However in many cases, the answer actually comes back more along the lines of “There’s 5 or 6 different API’s for that, which one do you want to use?”, and then as an app developer or POS integrator you have to choose. What’s the one API you’re going to integrate with? Or do you invest the time and effort that it takes it integrate with several of them? And the extra time it takes to maintain those integrations?


For Example

Say you’re creating a solution that allows a user to browse and purchase digital music from within your application. Amazon offers an API that will let you do exactly that. And so does Apple. And so do Bandcamp, Spotify, Murfie, and others. Each one may offer some catalog items that the others don’t. And wouldn’t it be great if your solution could seamlessly integrate with all of them?

Certainly, it would! But the cost of doing so is very high. Although each API ostensibly performs the same function, each one is independent and structured differently from the others. Where one codepath should logically suffice, you’re going to need five. Each one is going to have its own credentials, its own authentication strategies, its own API quotas and limits, and its own quirks that need to be smoothed over if you want your users to have a seamless experience. And once you’re done you’re going to have to track changes to each API and ensure your app is updated and maintained accordingly.


Thus the proliferation problem should be obvious. Unless you’ve got the development might of a Google, Apple, Amazon, or Microsoft there are more API’s out there than you can realistically integrate with. You’ve either got to settle for an integration with a single API and dealing with frustrated users upset that they can’t find any content from ‘API B’ within your solution, or else dive in and try to support as many parallel API’s as you think you can get away with.


A Better Solution

Imagine if instead of talking to a bunch of related API’s individually your application or POS system could talk to a single service that internally handled communication with each of those related API’s and then just shipped you the result. It might look something like this:


Doshii Industries API Integration


We’ve added a “middleware” layer that sits between your solution and the rest of the world. And now instead of talking to a whole bunch of completely different and differently-structured API’s your solution only needs to integrate with one API; the middleware’s. It’s connecting to the same amount of information, if not more, however, the complexity on the application/POS side has been drastically reduced. This carries with it a corresponding reduction in development, testing, and maintenance effort; or in other words, time and money.


Doshii Middleware API Integration Platform


You’ll notice that the middleware has a proper name. It’s called Doshii. Doshii provides API integration, management, and aggregation as a service. This frees up your time to focus on your actual product and saves you from having to worry about whether to integrate with one service or several and from the complexity and overhead associated with the latter option. And of course, it’s all accomplished through an API.


Strangely enough, it seems that the answer to the proliferation problem is yet again “There’s an API for that”. By leveraging a middleware API such as Doshii, your solution can gain the benefits of multiple parallel API integrations without any of the added development costs. There’s no longer a need to implement and maintain multiple codepaths that all accomplish the same logical task. And dealing with changes, updates, and maintenance as all of those API’s evolve? Well that all becomes Doshii’s problem; you don’t have to worry about it!


By placing a ‘middleware’ webservice between your solution and the webservices that it ultimately wants to communicate with, multiple integrations can be replaced with a single implementation and API proliferation becomes much less of an issue. The power and flexibility that this kind of solution provides are difficult to overstate.

Get Started With Doshii

Back to Top

App Integration

What to watch out for when integrating with Multiple Apps

Directly integrating a mobile app with pre-existing POS systems can present unique challenges not usually encountered when working with modern cloud-based APIs. These challenges can be both technical and business-oriented and tend to stem from the entrenched, walled-garden nature of most POS systems.

Read More

Back to Top

POS Integration

What to watch out for when integrating with POS Systems

To meet their business needs many venues will require integrations with various webservice APIs from their POS systems. While performing an individual integration does not generally pose any special challenge, small difference across APIs and schemas can quickly lead to increased complexity.

Read More

Back to Top

Doshii API Integration Best Practices

API Integration Best Practices Overview

There are a number of challenges that must be overcome when integrating with multiple external APIs. This article discusses some common design practices and patterns for doing so.

Data Modeling

The heart of any non-trivial application will be its data model. Ideally, you’re already using an ORM framework like Hibernate, ADO.NET, CoreData, ORMLite or one of a plethora of options for your particular technology stack, though whether you’re doing that or connecting directly to a relational database, or just writing your data out to some JSON or CSV (or proprietary format) datastore somewhere, some basic principles will always apply.


This first is that you should always model the state your application stores in terms of how your own business logic understands it. There are no bonus points for unnecessary complexity or convoluted relationships here. Just think about how your application needs to work with the data, what information it needs, and in what order it needs it, and go with the simplest design that works.


Once you’ve got a baseline data model that covers your core business requirements, it’s time to take a look at the external API’s that you’re integrating with and work out how they best fit into your model. The specifics will vary depending upon the features you’re providing, however at a high level what you want to do is annotate your baseline data model with additional fields provided by your external API’s. And you want to limit this strictly to those fields that are necessary for successfully communicating with your external API’s.


For instance, maybe an external API provides ‘Order’ fields like ‘orderId’, ‘purchaseDate’, and ‘revision’. In most cases ‘orderId’ will be the only field from that list that you actually need to add as a field in your data model. The rest is just noise that you’re better off ignoring.


API Integration Best Practices Doshii

Business Logic

Your business logic is the bridge between the persistent state within your data model and your application’s UI. It’s the glue that holds the app together and allows your end-users to accomplish useful things.


Having modular, extensible, and maintainable business logic is critically important to the long-term success of an application, particularly in the case of an app that relies upon multiple external API integrations.


When implementing your business logic, try to define logical operations based upon how your solution needs to work with or upon objects from its data model. Ensure that these operations broadly follow the principle of single responsibility; which is to say don’t have a ‘registerAccountAndPlaceOrder’ operation when you could instead have separate ‘registerAccount’ and ‘placeOrder’ operations.


Keep each individual operation as focused and concise as you can get away with, and allow more complex tasks to be defined as a series of operations. It may seem like a small thing, however putting in the effort up front to ensure that your business logic is focused, concise, and modular makes things much easier when the time comes to start wiring in external API’s.


API Integration Best Practices Data Doshii

Layering Abstractions

There’s an adage in computer science that goes roughly along the lines of “any problem can be solved by adding another layer of indirection”, and at a fundamental level, this is correct in regards to the problems introduced by external API integrations. We’ve already touched briefly on the broad classes of problems and challenges typically encountered in this space, and now that your application has a fit-for-purpose data model and some well-structured business logic we can look at some common solutions.


Business Logic -> Data Model

The majority of external API’s that you integrate with will act as data sources for your application. You’ll pass them a search query and they’ll send back a list of matches, or you’ll tell them to perform an operation and they’ll send back some JSON or XML describing the result. In most cases, you need to keep track of this information.


The problem is, of course, that even within the same category/domain/problem-space, every external API you integrate with is going to have a completely different data format. Even when they’re all describing logically the same thing!


To solve this, the first layer of abstraction you’ll want to add is one that sits between your business logic and your data model. This layer should be able to accept as input the raw data from any of your supported API’s and produce as output a populated, normalized object ready for insertion into your database.


Which is to say, if your business logic implements a ‘placeOrder’ operation, and this operation delegates to an external API for actually placing the order, then you should have a layer that can accept the raw order data from the external API and return an ‘Order’ object suitable for insertion into your application’s database.


What this setup does is it frees your ‘placeOrder’ operation, your data model, and any of your business logic that later interacts with the ‘placeOrder’ result from having to know anything about the external API that was used to actually place the order.


This means you’re now able to switch to a different API provider and/or connect additional API’s without needing to modify any of these things. The required changes are limited solely to the translation layer sitting between your business logic and your data model, which is hugely powerful and gives your app a great deal of flexibility!




Business Logic -> External API’s

At this point, you’ve solved the problem of getting information from an external API into your local data model quickly and easily and without needing to have tons of API-specific code sprinkled around throughout your application. That’s great!


However many external API’s will require an object to be carried forwards across multiple calls as part of its business lifecycle. For instance, maybe your user wants to cancel that order that they placed using ‘placeOrder’. The external API will likely provide a ‘cancelOrder’ feature, but in order to work it’s going to need to receive the object that it originally sent to your ‘placeOrder’ operation, and of course, it’s going to expect you to send that object according to its internal requirements. So we’re not done just yet.


The next layer of abstraction that you’ll want to add to your app is one that sits in between your business logic and and external API’s it integrates with. This layer should be able to take as input an object from your data model (in your internal format) and an operation (like ‘cancelOrder’), perform that operation by making the necessary API call(s), and then return the API response as output.


With this setup, your business logic remains free to work purely against its own internal representation of its data. All the mapping and translation that’s required to convert an external API response to an internal data object (and vice-versa) is handled by additional layers designed for that one specific purpose.


This keeps your core application code clean and focused, and again makes it very easy for you to swap out or add additional API integrations as your requirements change. This is very powerful, and all comes thanks to the addition of two relatively straightforward layers of abstraction.



Rinse and Repeat

Done correctly, the steps above should allow you to easily connect to additional external API’s that fit in the same category as the one(s) you’re already interfacing with. To connect to a new category of API’s (for instance, to enable a completely new in-app feature), simply repeat the process as needed. This does add work, but if you focus on only implementing what you need and adding features only as required rework can be kept to a minimum and the impact of breaking changes to an external API can be mitigated, if not avoided entirely.


Also, note that there may be various supporting bits and pieces that need to be tacked on in support of the layers described above. In particular, this may include things like configuration, credential management, and request signing for each individual API. Where possible this should be abstracted out to its own layer (yet again), so that these functions are decoupled from your core business logic, allowing either to change independently with minimal impact to the other.

Back to Top

API Integration Maintenance

API Integration Maintenance

How an API Platform dramatically reduces development costs when scaling

Whenever a third-party API is integrated with an application, long-term maintenance concerns arise. These concerns can be different depending upon whether a direct integration is performed or a middleware layer is deployed between the application and the third-party API, and the differences can factor when deciding which approach to pursue. In this article, we’ll provide an overview of API Integration Maintenance, and some things to consider when integrating.

Read More

Back to Top

API Integration Real-Time Communication

How Doshii enables real-time async communication between Apps and POS

API Integration Real-Time Communication

WebSockets provide a persistent, socket-like connection between two endpoints. Learn how webSockets and webhooks can be leveraged to reduce overheads and improve performance/responsiveness within an application. In this article, we’ll provide an overview of API Integration Real-Time Communication, and how webhooks and websockets help in bridging the communication between a server and client.

Read More

Feeling Stuck?

Doshii offers an out of the box solution that can provide your application many of the same benefits discussed above with only a fraction of the coding time, effort, and expertise required. We’re here to help so please don’t hesitate to get in touch for more information.


Get in Touch

Back to Top

Challenges faced by Apps during POS Integration


Directly integrating a mobile app with pre-existing POS systems can present unique challenges not usually encountered when working with modern cloud-based APIs. These challenges can be both technical and business-oriented and tend to stem from the entrenched, walled-garden nature of most POS systems.

POS Integration

Though somewhat of a niche area, there are use-cases that result in great benefit from integrating POS data with a mobile (or web-based) application. For instance, you may have an app targeted towards venue operators, each of whom will already be running an in-house POS system. And wouldn’t it be a great value-add for them if you were able to integrate with their POS and display statistics/analytics or other data from their POS system live, in your app, in realtime? Almost certainly it would!


Of course, there are some obvious challenges right off the bat. Different venues are going to use different POS systems from different manufacturers, and the available information may be completely different (or logically similar but structured in a completely different way) from one to the next. At an established venue, the deployed POS system may be all but antiquated; and even brand new systems can still lag behind industry standards and best practices by a significant margin. On the business side of things, POS vendors may seek to capitalize on the walled-garden nature of their systems, charging hefty licensing fees for access to their API’s, documentation, and hardware.


For now, let’s assume that we’re in an ideal world. Say there’s only a single POS system our app needs to integrate with, and that it’s provided by a forward-thinking manufacturer who sees that the benefits of creating an open ecosystem where any interested third-party developer can freely connect to their POS outweigh any gains they might get by pursuing a walled-garden approach to external integrations. That makes our job a bit easier. Our goal is, in essence, to integrate with the POS and consume data from it as if its a standard webservice API.


The first thing to realize, however, is that the POS is not a standard webservice API. To start with, there’s not necessarily a cloud-based API endpoint that you can just point your app at to start consuming POS data. While there are some cloud-based POS solutions available, if you want your app to work with the most commonly deployed POS systems you can’t rely on cloud-based solutions alone.  You’re going to have to build additional user-facing configuration into your app to allow users to specify the connection details of their POS terminal(s).


And once they’ve done that, things really get interesting. Unless you’re very lucky (even in an ideal world) the POS isn’t going to expose anything resembling a REST/HTTP webservice API. You’re just as likely to encounter an API built on establishing a direct socket connection between your app and the POS terminal, with information exchanged via a proprietary binary protocol. You may be offered the convenience of receiving data in JSON (unlikely) or XML (more likely), but equally common will be custom binary data formats that will require you to carefully marshall and unmarshall individual bytes, keeping track of endianness and other low-level details. It can require some serious developer talent, but hey, your users are worth it!


However, that’s just one POS system in an ideal scenario. Switch back to reality, where your users may employ any of 100 different POS systems. Go back to those configuration options you added to your app, and expand them so that users can select the type of POS system(s) they’re integrating with. Cater for the fact that you may need to collect a different set of information for each POS system you support. Give your users a way of notifying you if they need to integrate with a POS your app doesn’t currently support. Scrape together some venture capital so that you can pay the fees that POS vendors charge for the privilege of integrating with their hardware, and then the fun can really begin.


Now your app has to talk with a bunch of different POS systems, each of which is going to communicate differently from the others. So go back to your binary protocol implementation and your custom marshalling and unmarshalling code, and implement a version for each supported POS. And because firmware versions are a thing in the real world, and because vendors will often make minor tweaks to their APIs between firmware versions, go back again and implement different dialects of your communications protocol to handle all the different POS+firmware variations that your customers may be running (and be sure to thoroughly test each one!).


You also want to provide a unified experience for your users, regardless of which POS system(s) they’re connecting your app to. This means at some point your app needs to normalize the data it’s receiving to account for the fact that each POS is going to have a different way of representing the same logical information. For instance, an order in one POS system may come through as 3 separate entities:

doshii pos app api integration erd

  • The list of orders that were processed present on an Order Table.
  • The actual food/drink items which were ordered may be detailed in the Line Items table.
  • The details of the payment would be present on a Payment table.


Another manufacturer’s POS may track the same information using the same structure, however, they may store the same data differently.

  • POS #2 may keep the same 3 entities
  • however in POS #1, the transaction is stored as a timestamp data type, and in POS #2 the transaction could have the date and time separated to their own columns as date and time.
  • The date in POS #2 could be stored in US format
  • The reference codes for employee IDs in POS #2 are integer values, however, in POS #1, they were stored as a string
  • POS #2 may keep track of any customisation of line items on another table altogether


While a third POS might have a different structure:

  • They may have a different table structure which contains all the details of the order on one table

doshii pos app api integration erd


Your app will need to support all of these formats, with logic to select the correct one based upon the particular POS system it happens to be talking to and to translate it to/from its own internal representation. Analysis will need to be completed for each integration, with strategies defined to convert to a standardised format. This will need to be documented to ensure the integration can be maintained efficiently. As well as the actual development, testing, and ongoing maintenance effort.


All told it’s a significant amount of development effort, but the end result is a new feature that your users will love!

Feeling Stuck?

The challenges faced when attempting to integrate an App with multiple POS systems can be quite daunting. But don’t worry, we’ve been there before and have experience solving these exact problems! Don’t hesitate to get in touch for more information, and start your free trial today!

Start Your Free Trial