How to get more API users: 6 tips for success

I recently helped a company that wanted to improve its developer experience. Their quarterly goal was to gain even more adoption and new customers to their API in their native US market.

We did an API audit to their API developer experience. They are currently doing all the changes my thick audit report suggested, so I’m not mentioning the name. But let’s say they are among the best in their field and cater to the biggest customers, like LinkedIn.

Their API developer journey and that of their competitors had many issues, most of them very typical. For the benefit of all product managers and developers, I wanted to share a few tips. Let’s make the world a better place for API consumers.

But, first. Let’s state the obvious.

Value-First, Not API-First

First, you really need to understand who are or will be your API users. What benefits would they expect from your API.

If your API is providing users with a valuable service or data, then they will be more likely to use it. Think of ways you can make your API stand out from the competition and think about potential customer needs that you can meet with your unique offering. Once you have identified what advantages your API provides, promote those advantages on various digital platforms.

But before you go to offer your APIs to 3rd party platforms, you need to do some homework on your own channels and your APIs.

Your Site Must Not Be Pretty

Keep the graphic design of your API documentation or API portal in sync with your brand but still convincing to your developers.

Your potential API users need to find your API. If you design a pretty site with excellent graphics, it might still not speak to the developer’s soul. Developers want your site to look a bit rough. It’s best if it’s full of technical details. Cut down polished graphics screaming: “You need to talk to the sales first!”

I also compared their competitors’ developer journeys as part of the API audit. We ignored a few early candidates because you needed to talk to the sales to access the API. You might be tempted to think this was a good thing. Your competitors should not get to your API too quickly. Remember, though, the forms I needed to fill out and the messages I got back were downright off-putting. So as a developer, I would have run far from those anyway.

Is Your API A Hidden Gem?

Your API documentation must be linked to your main website navigation.

Stop for a moment. Look at your main brand website. Imagine you are a prospective client or partner who thinks the API is a “delighter” feature. They might not be looking for an API, specifically. They could be project managers, product managers, architects, or business people. So make sure your API stands out in the main product pages and doesn’t hide it as the last link of your website footer.

There are also many other ways to discover your API, but this is the no-brainer thing to fix.

‍

Make Love, not War with Developers

Your API documentation usability starts from having clear descriptions of value. This means value propositions for each API. It is completed by having standard API designs with up-to-date useful working examples. 

• A developer must understand in 3 seconds why you are offering the API and what problem does it solve?
• 30 seconds should be enough to try out the API and make the first request
• A developer must be able to use the API within 3 minutes from her code

This sounds like a tough call, but I’m serious. If your developer experience and customer journey are not up to those metrics, your prospects will move on to the following API. Or if they are your internal developers or hired help, they will be unmotivated and bill you more. Unless your API is doing something no other API is solving, or if your company is the best in its field, you might get away with a slower process. But don’t bet on it.

Some companies have solved this by offering only code examples as API documentation. They seem to think that jumping to the last step of the process is the most important one. But no, don’t take shortcuts. If potential API consumers do not understand why they should use your API, whatever code you throw at them won’t help.

That doesn’t mean that offering code examples or SDKs wouldn’t be good. They are if you have the resources to maintain them. If your GitHub repo says “last updated four years ago,” your developers will read “abandoned” and move forward. No programming language in the world would not need some updates every year. And your API has probably been updated anyway, so what are the chances that your SDK would work anymore?

Make sure there is a process for answering questions and issues coming through the SDK repository from developers. Also, consider that your developers might not have the best bedside manner when someone is “criticizing” their baby.

Roles and Tools to the Rescue

The API product manager is essential for a successful API program. Someone also needs to in charge of developer experience and relations.

By now, you probably think that providing an API requires an army of developers and developer experience specialists.

No, but your API does need an API Product Manager. And I don’t mean a Product Owner used in Scrum, but a Product Manager, who treats the API as a product with customers. Their job is to explain to sales, marketing, customer service, and developers what problems the API is solving. How does it provide value to the customers?

Also, it’s the API product manager’s job to see that all the documentation and the developer journey are working. The API product manager needs to work together with a developer relations or community manager. Their mutual job is to ensure issues and feature requests coming from your community get prioritized and answered.

A Quick Touch Up or Complete Demolish?

What you need to do to improve your API developer experience depends on the condition of your existing APIs and API documentation. The essential starting point for REST APIs is to use OpenAPI definitions for your APIs. As the API product manager, you must insist on this. It will help your API developers to automate documentation processes and ensure standard experience. There are tools that help developers do this, and enforce API design style guide rules.

What about the code and the SDKs, and the documentation? Create your API using OpenAPI specification. Or at least generate it from the code. Then you are already halfway through getting documentation and code examples. Make sure your OpenAPI documentation includes request and response examples. You are then able to use API management platforms or open-source tools. Tools can automatically generate documentation and code examples in various languages. This has a couple of other benefits, too. Your API consumers can use the OpenAPI definition in their code and automated testing. You can use the OpenAPI definition also for mocking (= simulating) the API before any or all the code has been written and to create tests.

Key take-aways

We started with the question of how to get more API users.

The easy answer is that you need to market your APIs, which is a topic for another post. 

The tricky answer is that the developers who find and use your APIs will be happy enough to convert into paying customers or valuable partners. This means you need to work on your API developer experience. So check that you have these things in shape or put them in your backlog. 

1. Research and confirm your API user segments and design your API documentation and APIs to create value for them.
2. Check that the graphic design and content of your API documentation or API portal. Make sure they meet brand requirements for trustworthiness and other API user expectations.
3. Check that the APIs are easy to find from your brand website and other marketing and sales channels.
4. Create and validate the API value propositions, and check they are visible in the API documentation.
5. Make sure you have someone in charge of API product management and developer relations. This person should be internal or at least hired with a long contract.
6. The APIs meet technical standards and examples.

‍