If you're looking to hire a development firm to build you a mobile or web app, this Quick Reference Guide is a must-have.
It happens to the best of us. You find a really great piece of software to send invoices through, another really great piece of software for time tracking, and yet another one to plan and track employee tasks.
Before you know it, you have handfuls of disparate systems that don’t speak to each other, and more of your team’s time is spent clicking from one piece of software to the next than it is actually completing work. Even if it’s only a minute here and there, these tasks add up day in and day out just like manual processes do, accumulating to weeks of time wasted each year.
Alternatively, if you’re in the process of developing applications for your customers, many users have gotten used to the quality of life improvements that integrations offer. Making these standalone services “speak to each other” has become a billion dollar industry.
Before you dive into the wild and confusing world of software integrations, we wanted to provide you with a handy guide to outline key terms, the questions you should be asking, and what to expect as you look to integrate your services or apps.
You might have heard the term API thrown around a lot, especially in the world of applications. API stands for Application Programming Interface, and it is basically a phone cord between one piece of software and another. When you go into your Uber mobile app and it asks if you want to log in through Facebook or Google? Those are APIs. And when you’re trying to find that perfect flight on a travel website, they know that WestJet has seat 27A open on tonight’s red-eye through an API.
APIs work by sending a request from your software to the connecting software, which then sends a response back — with the information that you’re looking for, if it’s set up correctly. Continuing our phone analogy, it’s just like when you call your sister every day to get updates on how her latest baking craze is going.
Another term you might come across is webhooks. Where an API is your software calling another software and asking for an update, a webhook is like that other piece of software texting you automatically whenever an event occurs — just like your sister sending you pictures of your niece whenever she does something cute.
Many companies know that you want to access their data, and like making it as easy for you as possible. In fact, there are almost 24,000 publicly available APIs in existence, and that number is increasing every day. Services like Google Analytics and Facebook want you to use their APIs so much that they’ve made them as robust as possible, with large quantities of documentation, frequently asked questions, and help desks to assist users.
Unfortunately, APIs are limited by the information that the company wants to provide. In our phone call example, if you asked an acquaintance a very personal question, you might not get an answer. And just like people, some companies are more private than others.
Additionally, while companies like Google provide a lot of documentation and instruction on how to use their API, others might have very little documentation, outdated documentation, or no documentation at all! And even though sites like Google and Facebook invest a great deal in developing and supporting their APIs, it’s important to note that even the best-supported APIs are under the control of someone else. The API controller could turn it off, start charging for it, or completely reconfigure how it works. For larger organizations like Google, that change is rarely sudden, but it does happen (and is something to consider in terms of evaluating the risk).
It’s important to note that while APIs allow for developers or services to create integrations with your platform more easily, APIs themselves aren’t integrations. Continuing to use our phone example, an API would be your cellphone, useless without a service provider. The integration is what is actually making the call.
Navigating the wide world of integrations can be challenging, which is why integration services like Zapier, IFTTT and Integromat have seen a rise in popularity. While they charge a fee for the ease-of-use they provide, if you have fewer development resources and the integrations that you’re looking to set up are supported, they can be the best option.
However if you’re looking to use one of these services, you should first confirm not only that they allow integration with the service that you’re looking for, but that they also complete the specific action that you’re looking for within that service. That is to say, it relies on both the integration to the service existing, and the action you want to perform being an option.
For example, you could set up your email to automatically save files and media sent to you to the cloud, but it might not have the option to save files to a specific folder. (This is just an example, and may or may not be true depending on the service.) If you want to adjust or expand on the integration, it might not be possible through the integration service, or it could be costly to work with the service to customize your integration.
Sometimes the integration that you’re looking for just… doesn’t exist yet. Especially if you’re working with your own custom web application or a niche product or service. These integrations will need to be built from the ground up specifically with your app or product in mind, and will require time after launch to be maintained and refined.
If you’re looking to build a custom integration, you will first need to research that the software that you’re looking to integrate with has an API or webhook available for you to use. It is also important to consider who will be maintaining the integration after initial launch, and the amount of effort or resources that will be required.
While building a custom integration can be a large investment of time, money and resources, it does come with some key benefits:
When evaluating the costs and benefits of an off-the-shelf solution or an integration service vs. a custom integration, there are two important questions that we always ask:
If you don’t have the technical acumen within your organization to scope out whether an off-the-shelf or custom solution is right for you, we recommend contracting a third party to help with this evaluation — and not just because we’re pretty proficient at this type of work ourselves. Often, this takes the shape of a Discovery process.
Congratulations, you have now graduated from Integrations 101. With the items provided in this article, you should now be equipped with the tools to evaluate integration options and propose solutions to technological problems, both internally and for your customers.