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:
- 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.
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.
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!