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

App Integration: What to watch out for when integrating with multiple Apps


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

App Integration Challenges

While starting out on a basic API integration from a POS system is really no different than performing the same task from any other context, there are some issues that will almost invariably start to creep up as the complexity and the number of App integrations grows. One of the most common challenges encountered early on is the additional data-storage overhead and related bookkeeping that’s required to “close the loop” with an external webservice.


For example, your POS system probably already has its own internal understanding of an “Order” and a way to uniquely identify an Order within its own internal context. However, say you’re integrating with a third-party webservice such as Uber Eats or Deliveroo that may push Orders into your POS system. This is a great way to stay ahead of your competitors and deliver a win for your customers by reducing the number of independent devices they have to deploy within their business.  However, each external service is going to have its own understanding of what an Order is, and its own way of identifying an Order, and it’s not going to be identical to what’s used within your POS system.


If your only requirement is to receive an Order from an external source, then you might be able to get away with fudging it a bit by simply creating a new Order in your POS system whenever the external webservice tells you to. However that’s seldom the case, as often you’ll want to provide updates back to the external service, such as confirming that the Order has been successfully received and/or notifying when the Order is ready for pickup and delivery.


To do that you still need to create the Order in your POS system when the external webservice tells you to, and you also need to annotate your order with extra information from the external webservice API. The core issue here is that your POS system isn’t going to understand Uber’s or Deliveroo’s Order IDs, and Uber/Deliveroo aren’t going to understand yours. Thus you need to store both IDs, and be careful to always use your internal ID when dealing with your inbuilt POS functionality, and the third-party ID when communicating with an external webservice.


That may not seem so bad, but what if you were integrating with both Uber Eats and Deliveroo so that your POS can work with either service (or both services together)? Now for each order, you need to know its internal identifier, whether or not it came from an external API, which external API it came from, what its ID is in that external API, and any other data from the external API that may be relevant and trackable. For instance, the data from an Order provided by an Order Ahead App may come through as three 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 Order Ahead App may track the same information using the same structure, however, they may send the same data differently.


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


While a third Order Ahead App 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


All are similar and all record essentially the same information. However each table has slight structural differences in terms of field names and types; they’re not directly compatible with each other! And as a POS integrator, your options for solving this problem are somewhat limited. You can put a translation layer between each API and your data-model to normalize the fields down into a single, canonical model. Or you can tack on additional ad-hoc fields or tables to accommodate each different variation of the data.


Either approach adds complexity and maintenance overhead, and either approach may introduce system overhead and lead to performance issues if not carefully planned out and correctly implemented. The more APIs you integrate with the greater this complexity becomes and the greater the risk that errors and subtle issues related to all of this mapping and indirection will start creeping into your solution.  And the complexity may further multiply as you encounter different communication strategies across your supported APIs; some may expect a standard HTTP request, while others may want to periodically poll your system for updates, while others may seek to leverage WebSockets to accomplish the same end. Your solution made need to accommodate any or all of these, switching seamlessly between them as needed.


Thus, while performing the first integration from a POS system to an external webservice API may seem like a straightforward undertaking, it’s critical to be aware of the hidden complexities that are lurking just around the corner and to have a plan for dealing with them.

Feeling Stuck?


The challenges faced when attempting to integrate a POS system with multiple Apps 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