APIs are table stakes

I have sat on both sides of the table as a consumer and builder of APIs. Working for product companies has given me an appreciation for the importance of making APIs a core part of product strategy.

As a customer with access to technical talent, fewer things frustrate me more than being asked what I am trying to achieve before I am given access to your API. Don't ask me what I am trying to do; show me your API documentation and let my product team and software engineers figure out what we can build. Truly innovative products emerge when skilled people and wild ideas intersect.

With that in mind, if you are a product company, here are some important considerations when developing and marketing an API.

Focus on developer experience

Good developer experience (DX) matters. Developers are your customers and influence the decision making process. The distinction between whether you build a REST, GraphQL, or gRPC API matters less than how easy it is to use and how productive developers are with it.

Documentation matters

Even if your team develops what is considered to be technically the best API in your market, the value of it is worthless without great documentation. Your documentation should use the Stripe API as the yardstick and it should be accessible in HTML format. Clearly outline the following details for your API: security; pagination; rate limiting; response codes; resource types; and request/response payloads. If your API is designed using OpenAPI, tools exist to generate basic documentation in the event you need scaffolding. You will know you have done a good job if you see HTTP requests being sent without a flurry of follow-up questions.

Ensure it is secure and performant

Gives users of your API confidence that it is secure and performant. Functionality counts for nothing if your APIs are vulnerable to the whims of bad actors. You need to stand in front of customers and affirm you have put security at the forefront of your solution architecture and you should understand the security posture of the API by penetration testing it.

Market and promote it

At the risk of stating the obvious, your API is a product. Decide how you will market it and whether you will sell it or give it away as part of your platform use. Only charge customers for your API if you have legitimate business interests to protect or have invested significant amounts of money in developing it. If your core product is already considered expensive, provide API access at no-cost as this will make your product more "sticky".

Evolve slowly

APIs are a public contract. When you evolve your APIs, avoid introducing breaking changes. Only add fields to payloads and if you have to deprecate functionality, give sufficient advance notice to your customers. If the rate of change in your internal APIs is frequent, consider building a public-facing API which evolves independently and at a slower pace.

Concluding thoughts

Great products that have extensible architectures use APIs at their core. As a SaaS company, you must have an API strategy and put developer experience at the forefront. If you are a Non-SaaS company that doesn't have APIs, you might have to fend off cowboy developers who's idea of integration is connecting directly to the operational databases.

Do whatever you can to develop a simple, secure REST API to prevent data backdooring.