Almost every project we build these days utilizes some level of third-party API integrations. So many software providers tout the ability of their product to be accessed and data manipulated via API capabilities. It isn't uncommon for a custom software project to be nothing more than a series of complicated integrations between third-party providers.
However, clients are often not aware of the downsides of such an approach. Whereas in the past, a website would primarily depend on itself and specific local software libraries, today, websites and web applications are offloading responsibility to external systems, exposing them to a new risk area.
In this post, I want to approach some tactics that can be used to mitigate these risks, both when determining which third parties to work with, integrating into those systems, and utilizing those connections for the long term.
Evaluate Risk Areas
An essential part of the process when developing your software architecture is to determine what risk areas may exist when utilizing third-party integrations. For the most part, a third-party offering an API will cover the most common security and availability concerns. That's not a guarantee, but generally, those factors would already be considered.
When I speak of risk concerning a third-party integration, I mostly talk about how the API could affect your ability to do business later. This happens in two ways. First is the reliability of the API's operation. We'll discuss this more in the future, but it's essential to know that your system can survive during downtime or instability with the API provider.
Secondly, there is a risk that the API provider changes their business model or way of doing things, including their pricing structure, which could negatively affect the way your application works. In this case, it's essential to know your alternatives and how quickly they could be implemented if needed. This is always a risk for licensed software, it needs to be considered.
Choose the Right Partners
The first step to building a successful API integration begins with choosing the right company to partner with. As I mentioned, many third-party integrations are now cornerstones for custom development projects. Because of this, project owners must determine the most stable, redundant, and secure partner systems to integrate with.
Another consideration in choosing a partner is the health of the partner's business. This is an area where I would always recommend a more established partner versus a startup. This is because startups have a habit of going out of business. A company with a proven track record, and a long history of API as an offering, is almost always better to work with than a startup. Startups also have a habit of changing the API so quickly that you can't keep up with it. As an API changes, it means more development work for you, which means more budgets and development cycles.
From the perspective of doing the work, I always tell clients that the most important things we need to complete the job are proper documentation, ideally updated regularly, and a human being to talk to just in case things don't work. If given those two items, chances are a project can be completed. However, a project can quickly go awry without clear documentation and someone to call if things go wrong.
Monitoring & Error Handling
Now that we've selected a reliable partner and considered some potential risk areas within that integration, it's time to turn our sights to the day-to-day operation and how it works. An essential component is some monitoring mechanism that is watching the API and ensuring that it performs up to spec.
Unfortunately, this is easier said than done. These days, some modern API monitoring platforms are available. Where things get challenging is what to do when the monitor finds a problem. While many monitoring products perform their task well, altering how your application works when an alarm is set off can be challenging.
Let me throw a hypothetical example out there. Let's say your website has an e-commerce mechanism, and your inventory is stored at a third party. That third party is necessary for any transaction to be completed. If the third-party API goes down, your application will stop working. In a case like this, you must know when the API is not responding, and the software automatically adjusts its behavior accordingly, even if only to show an error message. If an e-commerce system fails a transaction without some level of error handling that is human-readable, it could mean a loss of confidence for the customer, one which would result in them never returning.
In this example, error handling must be developed within the application to know when the API is not responding and display that human-readable messaging to indicate that there has been some sort of problem that is temporary. License monitoring platforms do a good job telling when an API is down, but utilizing them for error handling would mean that now you're not only dependent on your original third-party partner, but you're dependent on another partner to tell you that the first one isn't working.
Is your head spinning yet?
The biggest problem as a development firm is convincing clients that verbose, detailed error handling is necessary for API integration. This type of work takes time. The developer must predict many different scenarios and how to handle them. Also, we found that the best way to monitor is to do it yourself. Set up some scripts that call standard endpoints, and if they're not responding, change the behavior of your software. I like setting those scripts to run on a timed basis, sending an e-mail or text message to an administrator when an API call is not functioning correctly. This way, you're not relying on a third party to tell you when the other third party is working or not. Also, it's nice to monitor from the same IP, server, or network as your application. Many third-party monitoring platforms will be on various other networks, which may not mimic the performance of your network.
Manage Security
As part of this post, it's worth mentioning that there's always a risk when connecting to a third party, even via an API. The risk elevates as the data you're sending back and forth is more important. Most partners in the financial or healthcare space will have very stringent security concerns and regulations. Often, with recognizable partners, you need not be very concerned because they've already met all the criteria to maintain a secure environment.
However, if working with a startup or other smaller organization with an open or accessible API, you should inquire about their security practices. If a security breach were to occur, you could share liability with the partner, which needs to be investigated and ruled out as a possibility.
Again, much of this comes down to the business reputation of whom you're connecting with. Companies like Google, for example, make many of their products available via API. You never need to worry about using a partner like that, they've thought it all out. Sadly, you may need to think twice about the smaller companies that have joined the API revolution.
Conclusion
Undoubtedly, API connectivity has made the lives of developers and business owners easier than ever. As I mentioned, many of our development tasks nowadays include these connections - almost every project. So, working with third-party APIs is now standard practice and will probably never go away. And for the most part, that's a good thing. But as we've shown above, careful thought needs to go into protecting yourself and ensuring that your third parties are reliable, scalable, and secure
