Deliveroo partners with Doshii to bring down restaurant costs

Doshii is excited to announce a significant integration with leading food company Deliveroo. The partnership will streamline the processing of orders and make the delivery of Australia’s favourite restaurant foods to customers’ doors even more seamless.

Restaurants who partner with Deliveroo can utilise Doshii’s API to connect customer ordering direct to their POS. This eliminates the need for restaurants to manually process orders that come through the Deliveroo app. Doshii’s platform will be available to the more than 10,000 restaurants that partner with Deliveroo across Australia and to POS vendors as the preferred platform to connect to Deliveroo.

Deliveroo orders typically take around 90 seconds for restaurants to manually enter and process. The Doshii-Deliveroo integration will provide significant savings by allowing restaurants to focus their efforts and resources on front-of-house operations, reducing errors and making it even easier and quicker for staff to process orders. It will also help eliminate costly mistakes during the double handling and manual entry of the order from Deliveroo to the POS system.

Integrating directly with the POS will also remove the need for restaurants to reconcile between the Deliveroo App and the POS. This creates further time efficiencies for restaurants and their staff, who may have multiple order ahead apps that all need to be reviewed and matched up at the end of the month.

Doshii founder and CEO, Sean O’Meara, explains: “Doshii is more than just connectivity of Apps to venues’ POS systems. The platform and marketplace of Apps are designed to allow venue operators to select, trial and evaluate Apps to suit their business, all connected to their POS.

“The addition of Deliveroo to our growing number of connected Apps is extremely exciting, and fits with our expansion goals of providing a common platform to connect Apps to POS for the hospitality and retail markets in Australia and across Asia.”

Deliveroo Country Manager in Australia, Levi Aron, said: “At Deliveroo we are constantly innovating and looking for ways to help our restaurants grow. POS integration is the number one feature restaurants are requesting around the world, and it’s a key way that Deliveroo can help improve the performance of their business.

“Not only will this Australian partnership lead to cost savings for restaurants, but it will also see customers benefit from meals that are prepared and delivered faster.”

The Doshii platform, which connects Apps with POS in real-time, allows venues a variety of choice based on an open ecosystem. With recent investment from Coca Cola Amatil, Doshii will continue to develop its technology to deliver value back to venue owners by allowing them to connect their favourite Apps direct to their POS.

Get started with a free trial of the Doshii API

Do you have an App you’d like to see integrated with your POS Software? With no upfront costs, what are you waiting for? Our secure sandbox trial environment gives you full access to App and POS API integration examples, documentation and dashboard – with simulated orders and transactions.

Start Your Free Trial

To contact Deliveroo, email joanne.woo@deliveroo.com.au, phone +61 409 330 731, or visit their website.

 

About Deliveroo      

Deliveroo is an award-winning delivery service that operates in 13 cities across Australia, with a network of over 6,500 riders. It is headquartered in London, with over 2,500 employees in offices around the globe. Deliveroo operates in over 500 towns and cities across 14 markets, including Australia, Belgium, France, Germany, Hong Kong, Italy, Ireland, Netherlands, Singapore, Spain, Taiwan, United Arab Emirates, Kuwait and the United Kingdom.

About Doshii

Doshii has been developing and providing leading API services for integration since 2016. It is supported by an outstanding team with more than 40 years of collective development experience. Doshii reduces the cost of building and maintaining integrations while providing a robust, safe and secure experience for customers.

More than 130 POS systems exist across Australia alone, and it’s technically impossible for this quantity to connect to the ever-expanding number of Apps being developed. Doshii solves this problem by allowing any POS or App to connect to its platform via a standardised API. This allows App and POS developers to focus on building great products, instead of trying to manage hundreds of potential integrations.

Based in Melbourne, Doshii is backed by Westpac Reinventure and Coca-Cola Amatil-X. It operates throughout Australia and is now rapidly expanding into Asia.

Doshii-PosPay integration connects the digital and offline worlds to drive customer engagement

Doshii is pleased to announce an integration with mobile customer engagement and payment platform PosPay. Doshii’s API, which connects Apps with POS in real-time, links PosPay with access to thousands of venues 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. This provides a strong branding experience for any venue wanting to promote itself to customers in a particular geographic location.

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.

Doshii GM, Greg Williams, says he and his team are excited to be partnering with PosPay. “I appreciate their goal of bringing the digital and real worlds closer together to improve the customer experience,” he says. “The hospitality industry is becoming increasingly personalised and augmented and PosPay is making big inroads in this area.”

PosPay CTO, Blake McIntyre, says the integration with Doshii means a more seamless customer experience and improved staff engagement. “The two go hand-in-hand,” he says. “Our integration means staff can operate more efficiently, and with less training, so they can focus on delivering an enhanced customer experience.”

PosPay features and benefits include:

  • Free installation and set-up in any restaurant, hotel and festival venue.
  • Real-time ordering and tracking.
  • Integrated payment gateway with orders paid upfront.
  • In-app venue branding with fast notifications when a customer is in range.

Get started with a free trial of the Doshii API

Do you have an App you’d like to see integrated with your POS Software? With no upfront costs, what are you waiting for? Our secure sandbox trial environment gives you full access to App and POS API integration examples, documentation and dashboard – with simulated orders and transactions.

To contact PosPay, email info@pospay.com.au, phone (029) 5613111, or visit their website.

Start Your Free Trial

Doshii-Beam integration brings businesses up close and personal with the right customers

Doshii-Beam Integration

Doshii is delighted to announce a partnership with payment and rewards platform, Beam. This global tech startup has offices in Dubai, Sydney and Gothenburg, Sweden, and is currently the leading mobile wallet app in the UAE. It also appears at number 5 in the Financial IT Pathfinder rankings for 2016/7.

Beam’s success pivots off its ability to generate incremental profits for businesses and savings for customers by helping with better decision making and applying synergies present throughout the purchasing value chain.

Doshii’s API, which connects Apps with POS in real-time, helps businesses seamlessly manage payment and loyalty Apps like Beam. Together, the Doshii-Beam partnership provides a frictionless experience for merchants and customers at point of sale.

Doshii GM Greg Williams explains that the payment experience on both sides of the transaction doesn’t change based on what payment method a customer decides to use. “Beam, plastic card, phone… it’s all the same,” he says. “The benefit of partnering with Doshii is that we are able to connect Beam to multiple POS providers with a single integration. This makes it super-efficient and economical.”

“We are really excited to be working with Beam, a 21st-century platform that’s changing the global payments and rewards landscape.”

For businesses, Beam uses its comprehensive analytics and insights engine to attract, retain and re-engage with customers.  Its smart rewards ecosystem, with attractive personalised offers, is the key to its success.

Customers love the ease and flexibility Beam offers when it comes to redeeming and spending their rewards. Every time they pay with Beam, customers are rewarded for shopping and can spend their rewards anywhere Beam is accepted.

With research showing people check their mobile phones around 80 times a day, Beam offers a super-convenient payment platform and provides ‘personalised curated offers and rewards’ for businesses, literally in their customers’ pockets.”

Beam co-founder and CEO, Serdar Nurmammedov, says: “At Beam, we’ve created a platform that treats payments as conversations, not one-way transactions. This allows us to remove fees and ineffective advertising from merchants’ lives.”

“The key to scaling this is a frictionless experience for the merchant and customer at the point of sale. We made the decision to partner with Doshii as their API Platform connects to multiple POS with only one connection for us – this is crucial in ensuring business will succeed.”

“Despite initial scepticism towards our solution, we have persevered and succeeded. Seeing solutions like Doshii coming into the market is really encouraging for businesses and consumers. With the help of Doshii, established businesses and emerging startups are able to offer their services to businesses with a single integration.”

Get started with a free trial of the Doshii API

Do you have an App you’d like to see integrated with your POS Software? With no upfront costs, what are you waiting for? Our secure sandbox trial environment gives you full access to App and POS API integration examples, documentation and dashboard – with simulated orders and transactions.

To contact Beam, email contact@beamwallet.com, or visit their website.

Start Your Free Trial

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

While most webservice APIs will support a standard RESTful request/response mode of interaction, some may provide additional or alternative options via webhooks or WebSockets. These technologies enable different means of communicating with an API, with strengths and weaknesses that vary depending upon the context in which they’re used.

 

WebSockets

WebSockets provide a persistent, socket-like connection between two endpoints (most typically, a client and a server). Although originally introduced as a JavaScript API through the HTML5 spec, WebSocket client libraries are available in most popular languages, including Java/Kotlin (for Android projects) and Objective-C/Swift (for iOS projects). When leveraged by a web-based application running in a browser, WebSockets immediately confer some important advantages, such as the ability to easily bypass the same-origin policy that restricts most other attempts at cross-origin scripting.

 

Regardless of platform/language, WebSockets allow for real-time communication between the connected endpoints. Either party to the connection can send data at any time, and the connection is long-lived, making WebSockets an ideal option for subscribing to server-side event feeds that may produce updates at infrequent/unknown intervals. The canonical example of a use-case that’s well-suited to using WebSockets is a web-based chat application such as Slack. There may be many users all occupying a single room/channel and sending messages at unpredictable times. Connecting each user to the server using WebSockets keeps the latency between when a user sends a new message and when the server receives it at a minimum. It also ensures that the server can then immediately distribute any new message(s) to all connected users as soon as they’re received, guaranteeing timely and consistent delivery to everyone in the conversation.

 

Prior to the introduction of WebSockets, this same use-case might have been addressed using interval-based polling.  As its name suggests, this would involve having each client endpoint periodically (most typically on some fixed interval, though occasionally leveraging more complex algorithms such as exponential backoff) invoke (or “poll”) a webservice API to check for updates.  This is a simple and easy to implement solution, however it runs into some issues when deployed at scale. In particular it leads to a constant load being exerted on the server-side even during periods of inactivity, and limits application responsiveness to whatever the polling interval happens to be.  For instance, if the client polls for updates every 5 minutes, then there may be a delay of up to 5 minutes between when an event occurs and when the client learns of it. This can be mitigated somewhat by reducing the polling interval, however doing so naturally causes a corresponding increase in client and server-side load.  Thus this approach tends to scale quite poorly and is extremely inefficient.

 

One step up from interval-based polling is HTTP long-polling.  This is a technique where a client endpoint makes an HTTP request to the server, which the server then keeps open.  If the server has new data to send to the client at the time it receives the request, then naturally it just sends it and the request is completed.  If the server doesn’t, however, then instead of immediately completing the request with an empty response the server will hold it idle for a time, waiting to see if any new events or updates arrive.  If/when they do, the server can use the idling HTTP request to immediately send the data to the client, facilitating near real-time delivery. This approach can be effective and scales more readily than interval-based polling, but can be complex to implement and remains more resource-intensive on the server-side than using WebSockets, which offer a more elegant and generally better-performing solution to the same class of problems.

 

While WebSockets can be quite powerful, they are not always the best solution to use. Because WebSockets are persistent over long periods of time, they require a stable, always-on network connection and active maintenance to be most effective. They are well suited to use-cases that require real-time or near real-time communication between a client and a server, particularly in cases where one or both sides need to be informed of events that may occur on the other side with little to no warning. For scenarios that lack this real-time requirement, a traditional RESTful request/response model may be more straightforward. And for cases where maintaining a long-lived, persistent connection with a server simply isn’t a workable option, webhooks may offer an alternative.

 

Webhooks

Most webservice APIs follow a standard request/response model. A client sends a request to the API server, and then the server sends back its response. These events happen on a 1:1 basis, and are always initiated by the client.

 

Webhooks supplement this model by turning it on its head, and essentially allow the API server to post unsolicited updates back to a client. To use a webhook the client will register a callback URL with the API provider. This step may happen well in advance of the client receiving any actual data from the API, and depending upon the API(s) you’re integrating with you may be able to configure various options such as what events you’re interested in and what data you need to receive for each one. In any case, when the API provider has new data that’s relevant to you, as the client, they will invoke the registered URL and pass new data along as part of the request payload. Your system receives the data, and can then perform whatever processing your application needs.

 

In essence, this is the difference between asking the driver of a bus “are we at Stop X yet?” every 5 minutes (traditional RESTful request/response model) and telling the driver when you first get on the bus to “please tell me when we get to Stop X” (webhooks). The latter approach is less overhead for both you and the driver (API provider), and also more likely to result in a timely notification that occurs very close to when the bus actually reaches ‘Stop X’. This makes webhooks ideal for situations where you want to know immediately when something happens but aren’t sure when it actually will.

 

Note that there are some factors that may limit or entirely prevent your ability to take advantage of webhooks. For instance, in order to receive a webhook notification, you must be able to receive an incoming request, most typically on port 80 (HTTP) or 443 (HTTPS). Network firewalls may block this ability, and NAT may frustrate it, or you may already have some other process running on these ports. You also have to know, in advance, what address the webhook needs to call. This is generally not a problem if you have your own server or a fixed deployment such as an on-premises POS system, however it can become a significant challenge if your application is running on mobile devices or otherwise in a broadly distributed fashion. At a minimum, the latter scenario requires some method of dynamically creating (and updating) webhook registrations with the API provider.

 

Thus, in many cases where an API offers both webhook- and WebSocket-based API’s the WebSocket option is preferable. However, webhooks can offer a viable alternative in cases where WebSockets simply are not usable, for instance due to constraints that make it impractical to maintain a persistent connection with an API provider but where real-time communication with the API is still desirable. Relying upon webhooks can also be a very low-overhead option in cases where passing data from the client to the server is seldom required or not required at all. In this scenario the client is able to consume events from the server in near real-time, without expending any resources aside from when it’s actively processing an event.

 

Conclusion

While most of the bread-and-butter work of integrating with webservice APIs will usually follow a RESTful request/response model, WebSockets and webhooks are powerful supplementary tools that can (and should) be leveraged to reduce overheads and improve performance/responsiveness within an application. They are particularly well-suited to use-cases requiring real-time or near real-time communication between a server and client. While WebSockets are generally preferred and in most scenarios come with fewer caveats than using webhooks, in certain cases webhooks can be a more appropriate choice. Which approach is best depends heavily upon the context of the application being built and the features of its runtime/deployment environment.

 

Start Your Free Trial

How an API Platform dramatically reduces development costs when scaling

API Integration Maintenance Overview

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.

 

API Integration Maintenance Basics

Virtually without exception, a webservice interface is a living thing that evolves over time. The adage of ‘if it ain’t broke, don’t fix it’ seldom applies in the realm of IT, and particularly when consuming a third-party webservice you should expect that its maintainer will be updating it at least semi-regularly and generally without regard to your preferences as a consumer of their service.

 

For the most part, API updates will fall under a small handful of broad categories:

  • New Features – Additional API endpoints that perform new functions, support for new parameters or output formats on existing API’s, etc.
  • Performance Improvements – ‘Under the covers’ changes to existing API endpoints, for instance, to reduce request processing time, allow more data to be queried in a single request, etc.
  • Security Fixes – Updates to existing API endpoints or response data to address confirmed or possible security vulnerabilities

 

While a quality webservice operator will often be able to introduce new features and performance improvements without breaking backwards compatibility, this may not always be the case. And even the best operator will introduce breaking changes to their API if doing so is the only way to address a known security exploit.

 

Thus when integrating with an API, it’s important to monitor it periodically both for breaking changes that require updates to your integration code as well as for new features that you want to take advantage of. Failure to do so or failure to respond to any breaking changes with a prompt integration update can lead to sudden breakages of your application as third-party endpoints are removed, relocated, and refactored.

 

The great news about the Doshii platform is that we guarantee backward compatibility. We always continue to develop and advance our API integration service, but at the same time making sure to support older features. We also follow a structured versioning roadmap, to minimise the impact on developers and make sure there is no confusion over our releases.

 

We discuss upcoming releases in our community forum, and developers have input into what features they’d like to see. The ideas and feedback submitted through our community forum have been invaluable and have become an important part of our development strategy. We practice abstraction across all subscribers to avoid the duplication of developer effort, and provide certification and clear terms of service. All to make our partners’ lives easier.

 

API Integration

 

Direct Integration

When integrating directly from your application to third-party APIs, scalability of your maintenance tasks becomes an important concern.

 

It’s good practice to monitor for any changes or enhancements to APIs to avoid breakages and allows your system to benefit from those changes. This applies to each API you integrate with; as you add more integrations your monitoring overhead increases, as does the frequency at which you’ll need to update your application code to remain current with each API, and the amount of time you’ll have to spend implementing those updates.

 

If you don’t keep ahead of API changes, you may find yourself scrambling to fix unexpected breakages as deprecated functionality is removed from third-party APIs.

 

Points to Consider:

  • Can respond to API changes immediately, taking advantage of new features as quickly as you’re able
  • Low architectural complexity, which you are fully free (and responsible) to control
  • Reduced hosting/operational/service costs
  • Development overhead grows linearly as more API integrations are added
  • All clients must install/update to the new version to benefit from changes or bugfixes
  • Sudden breakages are more difficult to address quickly
  • Backwards compatibility may not be supported by all API providers
  • API integration support is not guaranteed and must often be managed in-house

 

API Maintenance

 

Middleware Layer

When running a middleware layer between your application and the APIs you consume, the maintenance landscape is slightly different.  The middleware layer provides a natural place to preempt breaking changes, at least temporarily, making these tasks slightly less urgent. For instance, if a third-party endpoint has suddenly disappeared, a quick patch to the middleware instance to stub out calls to this endpoint and return some ‘harmless’ default value (such as an empty result-set) can safeguard things until a more proper fix can be developed and deployed.

 

This mitigates (although not completely) against client-side disruptions and allows you to implement a proper fix at your own pace. Often such fixes can be implemented purely in the middleware, avoiding the need to push an update to your actual client endpoints.

 

The same approach can also be used to take advantage of new features and performance fixes. In many cases, such changes can be implemented in the middleware without requiring any client-side changes.

 

Furthermore, If you’re using a third-party middleware layer, such as Doshii, then your maintenance concerns almost disappear.

 

You still have to keep your Doshii integration current, of course, but everything else becomes Doshii’s responsibility. Doshii will monitor supported third-party APIs for updates and implement the necessary changes on their end. You just need to monitor one API for one set of updates, regardless of how many different third-party APIs you ultimately access through Doshii!

 

Points to Consider:

  • Development overhead is constant no matter how many third-party APIs your app consumes
  • New features can often be deployed without requiring a client update
  • Sudden breakages are avoided, in cases where the middleware provider maintains backwards compatibility (as, e.g., Doshii does)
  • Provides access to experienced external support and advice for new API integrations and testing
  • Provides access to community and self-help resources, for any well-established middleware provider
  • New API features provided by integration partners are only available once they’ve been implemented by the middleware provider
  • Middleware integration costs will likely apply
  • Access to new integration partners without any additional development effort

 

How to Maintain APIs

 

Start Your Free Trial

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.

Chapters

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.

 

Communication/Protocol

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

 

Structure.

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.

 

Security

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

Overview

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

Overview

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

Challenges faced by Apps during POS Integration

Overview

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