A decade ago, having a public API seemed like a no brainer. The common thought was that if you built it, the developers would come. Not only that, they would use your API and innovate in ways your organization hadn’t imagined driving tons of value in the process. It’s not that easy though. There is a laundry list of items that an organization needs to address when starting an API program. Those include but are not limited to: getting buy in from all important stakeholders, getting the right team in place, designing it with an API first mindset when appropriate, and treating it like a product.
Even once your API is ready for production, it often makes sense to start with an internal use case before moving on to a select few partners. But what happens when you are ready to take the leap from a small subset of users to something more open? What are the things you want to make sure are locked down tight before rolling out an open API program? James Higginbotham offered the following tips for making sure your API is ready.
The first thing that needs to be done is a thorough review of your API security. APIs have a way of growing beyond their original use case and that growth can expose a number of vulnerabilities. Organizations should review all endpoints to make sure that the API is not returning sensitive data that puts users at risk.
Your API documentation likely needs to be improved. When the API is only used internally the gaps in your docs can be overcome by simply talking to the members of the API team. Outside developers can’t hop on your Slack channel nor do you want them to. Your docs need to address the questions that potential users will have on their API discovery journey. There are several styles of documentation, each appropriate for the steps of that journey. Make sure that your docs incorporate elements of each style to help your users as they become familiar with your API.
A key part of any good developer experience is to provide code examples. Developers want to quickly get started using your API and code samples offered in several popular languages are a great way to help them out. Higginbotham also suggests including demo applications that show developers more complex use cases in which your API can be used.
The fourth item on the checklist is to install an API gateway or management layer. Doing so can protect your API endpoints from being hit by unchecked requests from an app. Whether the usage spikes are the result of bad actors or simply bad code, a gateway can help protect your API from the resulting poor performance.
The final tip is to define key performance indicators (KPIs) so that you can measure the success or your API program. It’s important to select KPIs that align with the greater strategy and business model that you have chosen. In addition they can help you make sure that your API stack is performing as expected.
Of course these tips alone do not ensure a successful public API. As we have seen in recent years, many big names have scaled back their API programs. If your organization is considering taking that final step towards an open API, then these tips can help you be ready.