Any business or organization in the world can bring an API to market, but APIs are increasingly synonymous with the startup world. Entrepreneurs are using APIs to deliver their products for a number of reasons:

• They can provide a convenient, easily understood and accessible mechanism for getting an MVP in front of customers;
• Having an API in the market can provide crucial insight into the value of your product through feedback from the developer community;
• An API can be one of several channels for delivering your product or may be the product itself.

However, as with the majority of technology projects, delivering an API to market is a mixture of “must-do” and “can-do” tasks. Deciding what falls into the “must-do” bucket can be highly subjective, especially where REST APIs are concerned and the intense debate the subject can engender.

Getting an API to market should focus on delivering maximum value as efficiently as possible. In this post we look at some ideas that can help first-time API entrepreneurs achieve this.

Focus on the Product

If you are building an API you might be creating microservices and internal APIs as the backbone of your architecture: However, chances are you are also concentrating on building a public or partner API that is the mechanism for selling your unique product or service. For this reason you need to be sure to treat your API as a product, giving it all due attention in creating what’s important for your customers. The view on APIs as a product is an interesting one, and one that is often juxtaposed between the technical and business goals of APIs. Erik Wilde recently tweeted this about APIs and product companies:

you cannot do APIs well and not make components readily replaceable. that’s what makes it hard for product companies to fully embrace APIs.

— Erik Wilde (@dret) November 26, 2016

If this perspective is valid, then entrepreneurs bringing API-based products to market who want to excel as an API provider must also give their customers compelling reasons to remain customers: If APIs are truly replaceable, then this naturally reduces the stickiness of APIs as a product. With this in mind, treating your API as a product must ensure your developer experience is second-to-none: It’ll create a buzz around your product, will get your target market talking and create the stickiness that will be so vital to maintaining customer loyalty. There are a number of areas you should focus on:

• Docs: Deliver clear, concise documentation that tells your customers exactly what they need to know to get to grips with your API;
• How-tos: Ensure you complement your documentation with how-tos, examples and tutorials that bring your API to life. Where possible, tailor the experience to the context of the reader, embedding their API key or development access token in the examples to deliver ease of use;
• Monetization: Transparently communicate your monetization strategy from day one. For example, if you are initially providing a free beta that will be converted to a paid-for plan once your API becomes generally available, you should make your customers aware of this as it will increase their confidence in you and breed loyalty for the future;
• Agility: If you want to quickly scale your API then self-service is paramount, so ensure onboarding developers is as self-sufficient as possible. This needs to include both the external-facing portal and internal processes such as approving new accounts. Consider ChatOps or other ways of maximizing productivity for your internal teams.

Design Simplicity

While there are many absolutes in the world of REST APIs, there is still subjectivity regarding the optimal design for an API. The subject can be divisive, especially when discussing areas such as hypermedia and the view that APIs aren’t RESTful without it: Such subjects can engender furious debate that is quite technical in nature and isn’t always particularly constructive. Design simplicity therefore means avoiding such debate and focusing on creating an API that adheres to the majority of commonly espoused design practices for REST APIs while providing something meaningful to your target audience. Such an approach might include the following:

• Ensure your resource constructs are simple to follow, possibly limiting your root URIs to a single fragment e.g. /pets;
• Decide exactly how you will use various attributes of HTTP such as query parameters and headers and then stick to those decisions;
• Think about how to use your API hostname to aid simplicity. For example, you might include a major version number, or if practical use subdomains to demarcate different areas of your API that are logically separate;
• Ignore the hubris and think carefully about the extent to which you’ll adopt hypermedia. If it makes sense to go all out to create a hypermedia API that your customers will readily understand then adopt this approach from the outset;
• Implement a security model that is an appropriate response to the wants and needs of your customers. For example, if the most likely use case for your API is to create server-to-server integrations your security model could be very straightforward, only involving API keys to identify consuming applications while dealing with user identity as a data attribute;
• Above all else adopt API-first design practices, using an API description language to create your specification. Such a practice will allow you to focus on the needs of your customer as opposed to coupling your public API to the backend you may have already created.

Some aspects of your API will only be meaningful to the context of the product or service you are bringing to market, so be prepared to have some flexibility around these design areas. However, by focusing on design simplicity you’ll be able to create an MVP much more quickly.

Simple Approach to API Management

The need for API management has become pretty much a given when deploying APIs. There is a plethora of solutions on the market, including both open source and commercial products, as well as a wealth of subjective interpretations on the discipline. First-time entrepreneurs who are building a solution from scratch are uniquely privileged: They are more likely to be creating a greenfield implementation with a suite of RESTful APIs that require limited mediation, transformation or any other feature of API management that tends to be associated with exposing legacy services as a RESTful API.

For startups, the role of API management can therefore be contained to the core functionality it can deliver on behalf of the APIs it exposes, such as enforcing security, rate limiting, and providing management information on utilization. API management may also deliver elements of the developer experience, such as providing a portal and interactive explorer. At a stroke the criteria for making an API management product selection can therefore be quickly reduced to the core features, discounting many of the bloated (and often expensive) solutions that are found on the market and focusing on lean, easy-to-implement products.

Be Ready for the Next Release

Taking your API to market for the first time will get your product in front of consumers, but chances are it won’t be perfect and you’ll certainly want to add new features over time. You therefore need to plan for the future from the outset and adopt a versioning strategy that is sustainable, maintainable and above all simple for customers to follow. There are a number of common approaches to the often thorny issue of versioning:

• Many API providers incur the disdain of the “RESTafarian” community by implementing versioning in the URI;
• Others use HTTP headers, either amending the Accept and Content-Type headers or using a custom header;
• There are also various approaches which can effectively make your APIs versionless, such as using a homegrown method based on metadata (such as the approach employed by Badoo, which was explored by Konstantin Yakushev at our summit or a similar, full-fledged hypermedia approach.

Whatever method you choose ensure you adopt and publicize your versioning method from the first release: Doing this from the outset will inspire confidence in you from potential customers as they will understand the implications of taking on new versions. As with monetization, such confidence breeds loyalty and in the API economy, where one product can increasingly be transposed with another, inspiring customer loyalty is paramount. Moreover, you’ll need to provide documentation on your versioning strategy as overt support for versioning in the majority of API specification formats has yet to mature to a level where it is sufficiently expressive to provide all the information required.

Final Thoughts

Starting a new business venture and taking a product to market for the first time is tumultuous even for the most seasoned entrepreneurs. Using an API as the vehicle for your product can be an excellent way of both achieving speed to market and rapidly onboarding a new customer base. The key to success is using the value of an API to your advantage: By focusing on delivering an API that is easy-to-use and delivers a great developer experience, you’ll have every chance of creating a product that makes an impact in the market.