In 2019, TechCrunch wrote that APIs were “the next big SaaS wave.” Two years later, it’s looking more and more like author Daniel Levine was right on the money.

Twilio and Stripe are still the most prominent examples of what you might call “API companies,” but there are plenty of other examples of API-first companies out there: Square, Shopify, Algolia, Zapier, and others. In fact, in a recent Forbes article, Iddo Gino (founder and CEO of RapidAPI) asserts that “almost every company is now an API company.”

This is exciting news for those in the space, but might also bring trepidation for some — just because a company has been building APIs for a while doesn’t mean that they know how to market them as products. One big part of designing an API as a product is to make it as self-service as possible. With that in mind, we put together some thoughts on doing just that.

1. Decrease Time To First Call (TTFC)

Time To First Call is a vital API metric to track, and there are various measures you can take to improve it. Many of these tactics overlap with other suggestions in this article, such as providing sandboxes and using external tools.

With a traditional product unrelated to APIs, generating revenue is all about moving people through the sales funnel: someone visits the website, the product piques their interest, they sign up for a free trial or make a purchase.

The specifics might differ for API-based products, but the process is similar. Remove as many barriers to entry as possible to make it easy for potential users to make their first API call. In other words, lower the TTFC.

2. Provide A Sandbox For Testing

In a nutshell, an API sandbox is a test environment that emulates a production API. They allow API consumers to test their integrations, just like a staging area in web development, reducing the risk of errors when they deploy to production for real. That also reduces strain on your actual API.

Sandboxes are extremely valuable for paid APIs because they offer potential customers the chance to try before they buy. This could dictate whether or not they take the plunge and purchase. Sandboxes also help developers learn how to use the service — this is great for folks who prefer to learn through practice. For these reasons, you should keep things as close to the real thing as possible; a sluggish sandbox, for example, might deter some folks.

Maintaining a sandbox indeed has costs associated with it, although you can grab a free trial from a service like Sandbox. However, those costs could ultimately be an investment in your product. For example, sandbox logs might help you identify pain points or potential areas for growth.

3. Instant Account/API Key Issuance

In some cases, it isn’t possible to allow users to create an account themselves. That might be due to sensitive data, or it might be that you need to figure out the volume of data involved with that customer. But having to wait for manual approval will inherently make your API less self-service.

If you can, we recommend making the whole process as open as possible: allow people to generate an API key, let them use OAuth2 for authorization, and let them dive in headfirst. In other words, try to get out of their way.

Of course, there will be things you need to think about with a paid or freemium product. For example, you’ll need to look into rate limiting if you plan to offer multiple pricing tiers. In addition to warning users when they’re approaching their upper limit, consider how you can transition them as they exceed that number of calls with minimal disruption.

4. Engage With Marketplaces

Although it won’t be the correct route for every product, it’s worth looking into marketplaces that can expose your offering(s) to a wider audience. There are, for example, developers who make a living selling apps on the Shopify App Store using APIs.

As of late 2021, RapidAPI currently plays host to more than 30,000 APIs. That’s pretty close to the number of APIs, just under 25,000, in ProgrammableWeb’s API directory. Their API acceptance rate isn’t published, but these numbers are high enough that it certainly doesn’t seem like they’re trying to find reasons to turn submissions down.

It’s possible to submit an API to RapidAPI manually and, if you’re using a specification — more on that below — the process is fairly simple: you can specify it using UI, OpenAPI, Postman Collection, GraphQL Schema, or Kafka as appropriate.

You can add an API to ProgrammableWeb, too, although it’s worth noting that ProgrammableWeb doesn’t facilitate connections in the same way that RapidAPI does.

5. Comprehensive, Easily Navigable Documentation

Lastly, easy-to-understand documentation is a must for a truly self-service API. The lines between an API specification and documentation are blurry, and something we’ve written about previously.

However, it’s generally the case that using something like an OpenAPI Specification goes hand in hand with rigorous documentation. You can even use Swagger UI to automatically generate visual documentation from a spec.

Beyond that, looking at examples of excellent API documentation is a good way to figure out what to include. Just remember, in many cases, your documentation is the first impression you make on potential customers. So make it a good one!

Self-Service APIs

The strategies listed above aren’t rocket science. In fact, they’re things that many API-first companies are already doing. However, it might not immediately be readily apparent to newcomers why these tactics are necessary. Hopefully, if you’ve read this far, that picture will be clearer now.

Marketing an API-centric SaaS has a lot in common with marketing other SaaS products, or any other product for that matter, but there are nuances associated with it. Considering these nuances, and increasing your service’s usability, is the best way to maximize the chances your API has of being successful. Making your API more self-service is also a surefire way to decrease one-on-one customer support, thus reducing cost!