The development of an API is a cycle of never-ending choices — whether those choices be the specific architecture and design of the API or the long-term needs of your users, the development lifecycle holds a multitude of possible options for the aspiring developer. One of these decisions is whether to develop in-house or to use external clients — that is, whether or not to develop a first-party API or integrate with an existent or contracted third-party API.

Each of these choices have significant strengths and weaknesses; ultimately, the choice between the two becomes clear when certain factors are taken into consideration.

First Party API Strengths

• Incredible control over development, design, and implementation
• Ability to design for very specific use cases and security scenarios
• Ability to oversee the entire API Lifecycle

First Party APIs are those APIs developed internally. They are sometimes referred to as “in-house” APIs, because they are developed using internal talent, resources, and systems. These APIs are often developed as part of a protocol or project development lifecycle, included as a means to support further integration of services or systems for other APIs or clients.

There are a great deal of strengths inherent in the First Party API that make this format extremely attractive to a business. First and foremost, these APIs can be designed and developed within the strict confines specified by the developer. Because the API is developed in-house, the specific needs regarding integrated services, types of calls, and even call methodology can be dictated by the developer requesting it.

For instance, if an internal API is developed to handle the management of media in a way that renders data for mobile services while maintaining server security and integrity, this API can be developed with a very specific architecture designed for large amounts of data management and specific request formats and limitations for external APIs and developers.

Related to this strength is the fact that security for a First Party API can be custom-designed for very specific needs and overall system weaknesses. Each API developer has highly specific security strengths and weaknesses inherent in their overall enterprise structure — because of this, APIs developed in-house can be structured around these strengths and weaknesses in a way Third Party APIs can never match. Additionally, services that other APIs developers might miss, such as analytics and reporting, can be integrated early on to great effect.

Finally, an in-house First Party API is a great choice due to the simple fact that they can be controlled from start to finish — the entire lifecycle from development to deployment and retirement is fundamentally controlled in-house.

This is a huge advantage for developers — control over the lifecycle of an API is so fundamentally important and so powerful that it can’t really be calculated in monetary or time terms. Everything from the monetization and general promotability in marketing is changed during this phase. Allowing for a more integrated management of the lifecycle rather than opting for a generalized hope that a third party will understand your specific needs can make your API that much more functional and useful.

First Party API Weaknesses

• Feature creep and ballooning project scope is a real threat
• Increased time and resource expense
• As complexity increases, so does expense, decreasing the cost/benefit ratio dramatically

While there are a significant amount of strengths inherent in a First Party API, there are just as many weaknesses that may make the discerning developer look towards Third Party solutions. First and foremost is the fact of scope. There’s the old saying “you can’t see the forest from the trees”, and this is ever the fact with First Party development.

Developers tend to get stuck down “in the weeds”, and feature creep is a real problem for a project of any size — especially one whose sole controlling interest is the party developing it. In order to combat this simple fact of project management, ardent and strict guidelines on scope and intensity need to be laid out well in advance, complicating the development phase, requiring more levels of management and overseeing.

This brings us to our second major caveat — developing an API in-house can be very expensive. Forgetting for a moment the pure cost of developing an API (which is something we’ll discuss as a strength of Third Party APIs), the fact is that with greater organizational overview meant to combat feature creep and promote control over the API lifecycle, organizational bloat and resource cost increases. To review every feature, to oversee every developed item, to make sure the parts work as advertised to the “top brass” managers and officers of the company, there needs to be intercessory managers, project reports, time estimates, and so forth. This increases the cost above and beyond the simple licensing and integration cost of a Third Party API.

This all culminates into a broad category, of course — time, effort, and money will always be spent at a greater rate when developing internally than externally after a certain size of project. If your API does one simple thing, it will be cheaper to develop in-house than to license an API; conversely, if your API does many things with complex calls, it will almost always be more expensive to create the API anew rather than simply license it. This then becomes a cost/benefit analysis — what are you willing to pay for total control over your product?

Third Party API Strengths

• A different point of view, creating additional approaches to complex problems
• Decreased time and resource expense
• Access to outside talent, experience, and wisdom

Third Party APIs are those developed outside of the user – that is, if First Party APIs are “in-house”, then Third Party APIs are “out-of-house”. These APIs are often designed for a blanket purpose — say, connecting to a server and delivering content to social media sites. As such, they are far less specialized than First Party APIs. This category also includes APIs that are contractually developed, that is, those APIs that you hire a developer or development team to create on your behalf.

There are a great deal of strengths in having a Third Party API, just as there are a variety of weaknesses. First and foremost of these is the fact that you are directly benefiting from the knowledge of others. When developing a First Party API, you are developing using your own knowledge, perspectives, and corporate culture. While this is fine for commerce or branded uses, your corporate culture and approach is limited to only that which you provide for it — making it easy to choose a single path rather than better, cheaper, or more effective options. Diversifying your talent set and utilizing the experience of others can result in a much better final product than any singular approach could result in.

Secondly, and something touched upon above, integrating a Third Party API almost always requires less time, effort, and money than developing a new First Party API. Integration of a Third Party solution is simple — pay a license fee, integrate into your services, and make sure any security issues are addressed. Development of a First Party API, however, entails paying employees, building a framework from scratch, licensing or developing any dependent technology, going through the quality assurance process, and finding ways to monetize. These savings come at a price, however, as the decrease in price deriving from outsourcing necessarily comes from loss of control.

All of this comes at a significant cost which might be mitigated dependending on your purpose — if the end goal is to develop an API to then market to other companies, obviously developing a First Party API has costs that are acceptable, but if your end goal is to simply solve a small issue or create a small portal for a singular task, then those costs are harder to justify. Many of the functionalities that you may need to call already exist: integration of map services, tax data, long-term data analytics, and many other services already allow API integration. Developing these solutions internally would waste precious resources.

Finally, when outsourcing API development to an exterior development, you often have access to a larger and more diverse talent pool than you would otherwise have in internal development. While this is negligible in certain cases, i.e. when your company has a long history or you have veteran developers, the fact of the matter is that when hiring Third Party developers, you have the “pick of the litter.” Whereas developing internally relies entirely on the developer experience that is so crucial to the development process, integrating with external developers allows you to more fully vet development teams that might have more experience, a proven track record, and better actualization of conceptual elements.

Think of it this way — would you rather use your home team, or use a “dream team” that you yourself can construct? Sure, it comes with a price, but when that price entails licensing a sure thing from an established firm as opposed to developing a not so sure thing using your own talent, that price becomes a variable that might be acceptable.

Third Party API Weaknesses

• Third-party pre-made solutions might not fit your specific requirements
• Loss of control over the API Lifecycle
• Security depends on the thoroughness of an outside entity

Third Party APIs have a bevy of caveats that make them the incorrect choice for an array of situations. First and foremost is the fact that, if you use a Third Party API, you are not using something designed for your purpose — you are using an API designed for mass consumption. This means that, more often than not, your specific experience is not tailored to your clientele and may require “hotfixes” or “tricks” to perform.

Secondarily, you lack any control over the API lifecycle. While you can certainly contract the construction of an API to mitigate the purposeful design caveat, this adds significant cost and necessarily presents a situation in which you’re sinking money into a project with little control or oversight. At that point in time, the cost may outweigh the benefit of the Third Party API, making the First Party approach far more profitable and effective. Again, as a cost/benefit analysis, the more control you demand over the project, the more expensive that project will become.

Finally, you are placing the security of your systems squarely in the hands of an unknown entity. Even if you find a reputable company who has your best interests at heart, you are counting on their developers never making a mistake, their quality assurance clearing everything, and their upper-level developers having the foresight to provide increased security in an ever-evolving landscape of hackers and criminals. Your security needs should always be privileged. Integrated systems that provide authentication, authorization, federation, and delegation may rule out Third Party API development altogether.

An errant period or poorly implemented dependent service could make your systems fundamentally insecure — the best example of this is the infamous Heartbleed bug, where a single bug in the OpenSSL Cryptography dependency made hundreds of services vulnerable to hacking overnight. While this is certainly a risk in First Party development, that risk can be managed and mitigated early in the development cycle with a good deal of control, whereas Third Party development necessitates lack of such control.

Real-World Scenario #1 — First Party API

Assume a startup company is developing an application designed to integrate commerce services provided by their traditional website with the mobile experience. The application will present items rendered from a database of items and images stored onsite and tied into a warehouse reporting system, and provide a “buy now” button for users to order for immediate delivery.

The company considers their options. Because there is a great deal of commerce systems available for licensing (such as 2Checkout and Stripe) that provide basic payment processing, the company considers implementing Third Party solutions. Though these systems may provide the basic functionality required, their lack of user interface skinning and a lack of specific security features makes the developers of this app nervous.

Accordingly, they decide to develop in-house. By developing in-house, the developers know that a greater deal of security can be achieved, protecting their internal servers and services. Though the development lifecycle increases, in the minds of the managers, the benefits of granular project control and greater flexibility outweigh the total project cost increase.

Real-World Scenario #2 — Third Party API

Picture a new start-up company, aiming to leverage an API that locates the nearest restaurant of a given type and provides directions using the shortest route from your current location. For the app developers, it becomes clear that the real “meat” of the app — the directions functionality — requires a strong and powerful direction system tying into a database of maps.

A clear solution is already existent — the Google Maps Directions API provides exactly this functionality, and is available for licensing. Developing a First Party solution would require a lot of time, effort, and money, which would be an absolute waste considering the functionality that Google Maps provides at a fraction of the cost.

A good deal of control is lost, of course. If the app developer wants to brand the map results, they can’t do that through this API. If the developer wants to change the user experience by skinning the maps results, they can so with limited tools from Google, but are fundamentally limited to either Google skins or menu styles provided by either the phone or device manufacturer.

This lack of control is far easier to stomach when faced with the high cost of in-house solution development however, and in this case, the startup decides to implement the Google Maps Directions API.

Conclusion

Given that both categories have some pretty large drawbacks and benefits, when is the time to use each? Fundamentally, the answer is one rooted in purpose.

If a company requires control, then First Party is the clear choice. Despite the increase in cost, developing an API in-house necessarily results in total control over the end product.

If simplicity is required, then Third Party APIs are the clear choice. Integration of an already existent solution or the contracting of subtle changes to an existent client to match your requirements is far cheaper than full-fledged development. This of course comes with a decrease in control, but this decrease becomes far more acceptable as your intended solution reduces complexity.

It’s a clear balancing act, a scale with “control” on one end, and “simplicity” on the other. As your requirements shift between the two elements, with “control” affixed firmly to First Party and “simplicity” to Third Party, your solution becomes clear.