How to evaluate a 3rd party RESTful API?

To build a fairly complex online service today, it is inevitable that you’d have to utilize 3rd-party RESTful APIs.

Listen Notes is both an API vendor and a customer of other APIs. We provide a popular podcast API to more than 10,000 companies and developers (as of May. 2025). Meanwhile, we also use a bunch of 3rd-party APIs ourselves (e.g., Stripe, Braintree, Cloudflare, Stop Forum Spam, Amazon SES, Google Speech-to-Text API, reCAPTCHA, Rollbar, Datadog, Twitter API, Facebook API, Slack API, and more). As you can see, without using 3rd-party APIs, we couldn't build Listen Notes as a small team.

Enjoying a view from both sides of the table, we’ve learned plenty about how to evaluate a 3rd-party API, which may be very useful to you. 🤗

Listen Notes Podcast API

Listen Notes Podcast API or PodcastAPI.com

The 4 Main API Questions

Essentially, there are 4 basic questions that you need to answer regarding your API selection.

1. Should you build or buy?

First, please read this Wikipedia page: Not invented here.

Then ask yourself: Do you have to build everything entirely in-house?

There are primarily three types of costs to consider:

What’s the cost of building a functional v1? How many full-time employees do you need to allocate for this project? For how long? How about the cost of running your own servers? What if outages happen?
What’s the cost of future improvements and maintenance? Software projects rarely have a clear finish line. There’s no such thing as launching a software product then calling it “done.” You need human engineers to fix bugs, to add new features, and to do whatever needs to be done to keep the thing running 24/7.
How about the opportunity cost? The time and money you spend doing A is the time & money you can’t use to do B. If you want to build this whole thing in-house, what are you going to give up instead? What projects are you okay delaying? What product features are you going to cut? How long can you afford waiting while using a v1?

If it's obvious that it's too costly to build in-house, then you can start looking for 3rd-party APIs by Googling terms with "API".

Marat Minulin, Senior Frontend Developer with ABBYY, is currently developing an application that uses several external APIs. Within the 1,300-employee firm, the API assessment process starts with discussions inside the development team, asking what problems the API can solve, which solutions and alternatives already exist, along with the specific advantages and disadvantages each solution possesses.

“Everyone can express their opinion and have an influence on the API selection,” Minulin stated. “The final choice is made by a vote or, in the case of a tied vote, by the team leaders.”

2. Can this API provide all the features you need?

Okay, you’ve found some promising 3rd-party APIs. Which one should you choose?

If an API doesn’t provide enough functionalities to suit your needs, then look somewhere else.

In some cases, an API provides 90% of the features you need, which may still be okay. You can get the remaining 10% of features by either building them yourself or finding APIs from other companies.

There’s no better way to evaluate the functionalities of an API than actually trying it out in the code. Many APIs allow you to get an API key in a self-service way, even without giving them your credit card info. On the other hand, some APIs may ask you to “request a demo” or “talk to an expert” first, which is quite annoying. Even with a few days delay, you can still get an API key after talking to those annoying sales people.

Alex Wan, Vinpit co-founder, uses a 3rd-party API and recommends first discovering your main goal of integrating an API, along with choosing an experienced vendor you trust.

“Before choosing an API provider, you should define the integration's strategic objective,” Wan said. “Before we begin work on a complex online project, we must first select a trustworthy vendor as many products go off patent. For a more accurate analysis, you should look at the experience and track record of the vendor.

“The subsequent step is to determine whether they have a high grade of the quality process so that you get your work done on time. Finally, verify that your 3rd-party vendor is capable of adjusting to any changing regulatory requirements.”

3. Is this API both stable and scalable?

You are using a hosted API that runs on other people’s servers. Ideally, you want the API to be up and running 24/7. And you want the API endpoints to be very performant — ideally less than 200ms (200 milliseconds = 0.2 seconds) response time in most cases, and rarely take longer than 1000ms, which equals 1 second.

You can build a toy web app using the API and monitor the performance for a few days. By doing so, you can get a rough sense of how fast (or how slow) the API is.

To evaluate if the API is stable (i.e., high SLA, little down time…), you can talk to their users, or search for any reviews on the Internet. Generally speaking, no news is good news. If an API always has outages, then people are likely to complain loudly on Twitter, StackOverflow, or Reddit. If an API is super stable, then you may find few complaints on the world wide web.

It’s all about the SLA...

Aleksandr Denisyuk is a PHP Developer with Orangesoft, a company that specializes in mobile app and web development. Denisyuk lists many criteria to help you choose the right API provider for your product: including proper documentation, a multi-language SDK solution that supports different languages, 99.99% consistent and strong uptime, along with 24/7 support with correct information offered when you need your questions to be answered.

Along with these indicators that minimize business risks, it is vital to examine the API service’s monthly uptime percentage in the Service Level Agreement (SLA) presented on their website or when signing a contract.

“If they don’t, or if you want to be confident that your partner is upholding their agreement, you may calculate uptime on your own,” Denisyuk stated. “In that case, you need the proxy to log both the outgoing API calls from your application and the response. And then, uptime is calculated as the proportion of successful requests over a one-day window.”

Also, try your best to figure out who is the largest customer of this API. That will help you assess if the API is able to support your scale.

Most serious APIs have a status page where you can check the historical uptime and response time, which could give you some insights into how stable the API is. For example, this is our Listen API's status page: https://www.listennotesstatus.com/

4. How easily can you talk to a real human employee of the API vendor?

Ideally, you should be able to talk to an engineer, or even better, the CEO, CTO, technical co-founder, and/or the VP of Engineering - anyone who actually knows their stuff.

Remember, you pay money for using both the software and human customer support individuals.

If you have a hard time connecting to human customer support staff who actually understands how the API works, then what happens when there’s a big outage on the API end? You’ll feel helpless.

You can do nothing!

You would have to apologize to your users: “Sorry! The API we depend on is down, but we are not able to talk to their customer support department!”

Your own customers don’t care about this API thing. Your customers would only blame you.

Many API vendors require you to upgrade to certain paid tiers to talk to actual human beings. This is understandable, because human labor is costly.

If the API will be critical to your business, then just pay and try them out (at least for a short period of time). Nowadays, most APIs (or SaaS) allow you to do free trials or buy monthly subscriptions. If you think a $500/month subscription fee is too much, then think about this: You are already spending $100/hour on a not-so-bad engineer -- including base salary, benefits, and perks!

A bad API choice could easily waste your engineers 10s or even 100s of hours! Don’t spend hours saving dimes and nickels.

So?

Oftentimes, you don’t need to make an all-or-nothing decision. There's middle ground:

You may use a 3rd-party API to quickly launch an (MVP) minimum viable product. When the product idea is proven, you’ll be confident enough to invest resources to build a decent in-house solution and replace the 3rd-party API.
Or you can use a hybrid approach by combining a 3rd-party API with some in-house solutions.

You are a resource allocator. You try to allocate limited resources (i.e., time & money) and come up with a practical engineering solution. It doesn’t need to be “pure” or “perfect” out of the gate. Your job is to solve customer problems. Customers don’t care if you build the whole thing from ground up or just use a $100/month API.

If you do end up using a 3rd-party API, make sure that you structure the code in a way that you can easily replace the API with either other APIs or your (future) in-house solutions. In this way, you can minimize the risk of vendor lock-in.

According to James Yorston, Solutions Lead at Codat, 3rd-party APIs can help customers avoid the painful experience of attempting to create the specifics necessary for their businesses.

“We handle all the heavy lifting involved in integrations, including authorisation, data standardisation, and ongoing connectivity,” Yorston explained. “This leaves clients free to focus on how customer data can improve their product or service.”

Human customer support is invaluable

Anton Yarkov, Principal Software Engineer and Engineering manager at Access Softek, Inc., a firm of approximately 350 employees that creates online and mobile banking solutions for Credit Unions, has extensive experience with APIs.

“I've integrated with more than one hundred FinTech enterprise-level API,” Yarkov stated, explaining that their client's community drives the company.

“So our clients choose what vendor would be most valuable for them in terms of the services it provides. The development team dives into technical weeds and evaluates efforts needed for the integration. Usually, the most straightforward APIs for the integration are preferable for the team.”

The most important attributes in Yarkov’s viewpoint include clear documentation, industry-level security, along with quality assurance and deployment of the API servers. However, the most detailed documentation combined with certified testing execution and production stages should be topped off with great customer support.

“It's worth mentioning that good documentation is valuable, but it is also nice to have technical personnel available to keep in touch throughout the integration,” Yarkov wrote. “It makes the process a lot easier if the vendor has somebody for on-call help when it is needed.”

More real-life advice for choosing a 3rd-party API

Bruce Mason, Delivery Director at software development company QArea, gave advice from his hands-on vantagepoint of working with API development and implementation.

“Good API should be segmented by categories: authorization and authentication, billing, content management, etc.,” Manson warned. He also noted that the API should include templates (wrappers), which could provide an easy example for integration with API and usually should use different popular programming languages (e.g., Java, Python, C#, or JavaScript).

Also important: Well-formed documentation that includes general documentation for the API with working examples of code. When it comes to testing, Manson states that the API should provide sandboxes for testing with test data. “It is really helpful during development,” he advised. Frequent feedback and keeping users in the loop by announcing future plans and updates is also vital.

Does the API have an innovative future?

Shyam Sivakumar, VP of Data & Analytics at Way.com, examines a plethora of factors and asks quite a few queries prior to selecting an API provider, including their innovativeness and adaptability.

"There are several things we look at,” Sivakumar noted. “The first is a feature set. Do they satisfy what we need currently and do they have what we will need in the future? We also look at support during and post-deployment. Do they have the complete and right documentation and responsive support teams in place? Finally, we look at innovation and research & development. Do they innovate in [their] space and have the ability to provide future use cases that will ultimately make our lives easier?"

Security is king! Don’t hand the keys to your company’s kingdom to API hackers...

Yariv Shivek, Vice President of Product, at Neosec - a company that focuses on reinventing API security and preventing “threats lurking inside” all your APIs by analyzing their behavior - adds the notion of supply-chain security considerations to the list of API evaluation criteria.

Shivek states that the final decision maker is the CTO, with inputs from architecture and product management - yet emphasizes that evaluating API supply-chain security is important to consider as well.

“Take for example the recent vulnerabilities found in GoCD APIs, which could leak GitHub API keys to attackers, quite literally handing them the keys to your kingdom,” Shivek warned.

Being able to quickly speak with an API company’s employee may indeed reflect the company's overall responsiveness, but that might not be enough, Shivek stated, recommending perhaps a more vital list of questions to pose to your API provider:

Ask yourself:

What sensitive information am I placing in the hands of the API provider?
How much do I trust them?
How quickly will they disclose a breach to me and to other consumers of their API?
How well do I believe they will handle such a breach?

And most importantly - stay vigilant!

Monitor your API traffic, both outbound (APIs you provide) and inbound (APIs you consume).
Be on the lookout for anomalies so you can act (hopefully automatically) when something bad or suspicious happens.

Overall, technical industry experts tend to point to similar archetypes at the surface level of evaluating any API: Chiefly, you’ll want to closely examine the quality of support and documentation offered, security measures, and how much the API will improve your firm's efficiency.

Eric McGee is Senior Network Engineer at TRGDatacenters, the most-reviewed and highest-rated data center in Houston.

“We examine its features to determine if they meet our needs, and if they can be instrumental in improving our efficiency and service delivery,” McGee advised.

“Another critical step of our evaluation of APIs is measuring the performance and reliability of each API we may be considering. Here, we want to determine how fast each API responds to requests, how long it maintains a connection without any errors, whether the API is susceptible to errors, and how these errors may affect the customers. Normally, representatives from the IT, procurement, sales, and marketing departments are involved in the evaluation process.”

Thorough API evaluation pays off

In the long run, it is supremely beneficial to take a deep dive into all of the above-listed factors when comparing the best APIs to use. The more detailed and thorough your evaluation process on the front-end, the better chance you’ll likely experience success by selecting a 3rd-party RESTful API that meets all of your needs, is extremely responsive, secure, and offers superb uptime as well as excellent customer support.

The worthwhile evaluation process will spill over to your customers in a beneficial manner, by providing them a seamless, secure, and stable experience.

More...

Learn more about Listen Notes, Inc.

Search episodes & podcasts: listennotes.com
Build your own podcast playlists: listennotes.com/listen
Build podcast apps with our podcast API: listennotes.com/api