What’s better: building API or buying one?

Is it cheaper to buy API rather than develop it on their own? What’s better: building API, or buying one? Some of you may be wondering whether it is better to use a vendor’s API or build your own. The choice between build or buy might be hard, but we will help you dispel your doubts. 

Well, developing your own API is complex. You have to deal with numerous edge cases and problems that may arise during and after the development process. The question is whether all of this effort is worthwhile. This causes a hard choice between existing API products and the “build my own” option.

There are many concerns and problems that may arise while developing APIs that you are unaware of. See the examples below.

API? I will build on my own, I don’t need any providers 

When you build crypto API alone, you don’t take into account a lot of corner cases. Cryptocurrencies are called differently, every API from various exchanges is different, and there are things that you don’t even think about it. Creating a reliable API is not easy and doable in a month. This might take months to create the first demo of the product that still needs improvements.

By integrating with CoinAPI, the customer has access to ALL exchanges. The cooperation with CoinAPI saves time, money, and the need to hire additional developers. Our main rule is “The client can focus on the development of its product, and not on the supporting tools they need to produce that we provide”.

Hiring developers vs finished product from CoinAPI 

Take a simple example. To build an API you need to hire at least two developers. The annual staff cost is approximately 200k USD. Quite expensive in comparison to a 79USD subscription free with CoinAPI. Not to mention the 24/7 support, infrastructure maintenance, and initial costs related to maintaining API over time. It’s simple mathematics, and this is why in many organizations integration with API is essential.

I will try open-source APIs 

Open-source tools are low-quality, not extensive, and so you have to spend time building them, aggregating, and getting the data you need. Usually free API Key offers one language, so there is already a limitation. They are aimed at people who write in one language. Open-source API keys are always with limitations, and their main goal is to give a chance to test the solution and see its basic functionalities. You can test the free CoinAPI Key here. When there is a problem with API, it is nice to be in a contact with support for assistance in resolving the problem. This isn’t always guaranteed with open-source APIs, and even when it is, the kind of SLAs you’d expect with a proprietary enterprise-class software suite aren’t always in place.

If you are planning to get open-source APIs for your critical projects, just be prepared to accept the risk of doing so. There are advantages and disadvantages, and it is critical to weigh them against your goals when deciding whether or not to use open-source.

If you aspire to build API, you must know the basics of the building process

CoinAPI made it very easy to define things in API, so the clients didn’t have to tediously do all of these by hand. So, in fact, CoinAPI saved a ton of time. The documentation became an easy one because, with the open API spec, you’re able to put in a lot of information. We can store the documentation in there, and then it is made so that we can simultaneously generate documentation and a bunch of other code.

The client’s focus is on generating business, not on building infrastructure and getting into those corner cases that we got into like data volume issues. There are an awful lot of things that the person who wants to build an API is not aware of.

What’s better: building API or buying one? By choosing the build option, you may run into the following problems: 

1. Poor data quality

2. Costs. It is very easy to overestimate the cost and underestimate the investment

3. Problems with integration with some exchanges. Some of them are not of good quality, and often you have to spend a lot of time to make the data useful for end-users

4. Quality.  You need to know how to deal with quality problems, and how to avoid them

5. Data normalization. When integrating the exchanges, the data must be normalized, which can be done manually (it will take a lot of time). Although it is impossible to do it faster, CoinAPI does it automatically.

6. Data aggregation and maintenance. As there is more and more data, very likely something will start to break down. Sometimes you have to completely change your approach to data maintenance and how the data flow should look like. For example, if there is a panic on the market, we have 10x more data.

7. Redundant servers. When one location is unavailable (e.g. it delivers delayed data), users are transferred to another. You are responsible to ensure business continuity so that users are not inconvenienced

8. Location redundancy. If one location, for example, fails, the question is whether the second location will be efficient enough to serve people from that location.

9. Load. The more people who register, the more load there is, and you must know how to manage it, because the application may eventually stop working due to a lack of infrastructure

10. Problems with backups and data restoration. Many businesses today still face significant problems with data restoration that can lead to data loss and significant disruption to business operations. Another challenge is the complexity of restoring data, particularly when it comes to restoring complex crypto data. That’s why it’s essential to work with a skilled and experienced team who can make a backup and data-restoring process.  

11. Infrastructure issues. You need to maintain the infrastructure, to be in many locations so that these locations communicate directly. To have the infrastructure you need to have another team that knows e.g. Amazon, hardware.

12. Team maintenance, reactions to any issues, ad hoc actions

13. 24/7 support

The Verdict: What’s better: building API, or buying one?

The strategy should not be based on cost savings, but rather on the expected benefits of using – or not using – open-source APIs. Good API should include support, documentation, training, and software development resources. Companies that contribute to the development of open-source software and become members of the community benefit the most from it. The concept of open source is based on the concept of sharing. Expecting to only take and benefit without contributing contradicts this concept and will not lead to long-term success.