My New API Vendor Evaluation Checklist

I am helping a customer think through their decision-making process around the adoption of a new API service, and while I am doing this I am spending the time to think through my own API adoption process. I like having checklists to consider when making new purchasing and integration decision. Sometimes I have an immediate need which is driven by emotion, and it can help to step back and think through a more rational checklist I established for myself on a previous date.

When I am approaching a new API that I think might move beyond just playing around, and actually have a viable business use case in my operations, I think through the following areas:

  • Define Value - What value is being created by an API I'm looking to use.
  • Define Needs - What needs do I have which using an API will solve.
  • Define Options - What other solutions are there beyond this API.
  • Think About Today - Is this an immediate need I have with days or weeks.
  • Think About Tomorrow - Is this a long term need that will go on for years.
  • Vet Company & People - More detail about the company, people, and investors.
  • Define Partners - What does my the partnership landscape look like for the API.
  • What Things Cost - What are things going to cost be for using an API.
  • What You Can Afford - Can I really afford using this service, or not use.
  • Develop Continuity Plan - What is the plan for ensuring stable operations using API.
  • Develop Exit Plan - How will I severe a relationship and replace or deprecate need.

Sometimes I do not have everything in order before I pull the trigger. I may not completely though through what I will do when an API goes away, but I like at least having some notes written down about my frame of mind when I was integrating with any API. Having the checklist to think about at the time of integration and purchase, as well as my notes about evaluation around a vendor provides me with something I can revisit each month when paying the bill, or may as I encounter a new service, or possibly instability or lack of access to an API.

I am using this as part of my own API operations, but I'm also helping a client think through their API purchasing decisions, and hopefully, make the process a much healthier and educated one. I'm hoping this helps put much of the burden of API stability on the shoulders of us people who are actually making the decision, allowing us to be more mindful of who we integrate with, and set more informed and honest expectations around what APIs do, and where some of the current business models in place might help, or hurt our plans.