How to Engage Your API Users

You have a kickass API—now it's time to get people to engage. The only problem is that this...

...isn't exactly sexy. Nor does it show what your API is capable of. You can show an example call or curl command, or part of the feed that your API returns, and none of that would even come close to showing off the well-designed API your team is so proud of building.

You don't want developers playing around with a few API calls and then calling it quits. You want devs to see its full potential. You want them to build it into their own software, and continue to learn how to do more and more with it. And the only way to get them to do that—is to interact with them. Here's how.

Collaborate With Your Users

Static documentation that is written as a one-and-done deal isn't going to engage your users. Developers are going to come to your page, browse through, get bored, and bounce. But all those devs are working on their own projects and are chock-full of great ideas on what can be done with your API. Not collaborating with them is a huge missed opportunity.

Create a community around your API so that you can learn from your users and adjust your documentation and design accordingly. Your community of developers will feel more invested in your product, and you'll learn more about what's possible with your own API.

Crowdsource Your Docs

If open source software has taught us anything, it's that hundreds of developers QAing a product is better than one. Same goes for documentation. Instead of creating a static doc, like the hundred-page PDF manuals of the previous decade, create a documentation hub.

One tool we've built into ReadMe is a “suggest edits” button so that your API users can correct any mistakes they find, point out places where clarification is needed, and ask questions.

One of our earliest customers, account security tool Clef, even includes a note on their landing page, encouraging developers to suggest edits.

Open up lines of communication

The more lines of communication you have with your API users, the easier it will be to stir up a community. Use several mediums to announce updates in order to get your API users excited about new use cases and help spread the word.

For example, here's Stripe's tweet announcing more app integrations.

And it's working. They have 80.9K followers, all interested in updates to their API. They also make sure that they make the announcement on the landing page of their documentation.

Try to fire on all fronts and engage users through several mediums. Other platforms you can use include:

  • Hacker News. If you're willing to put your API to the scrutiny of the Hacker News community, it's a great way to stimulate conversation around new updates.
  • Product Hunt. Make sure that your post meets the community guidelines. Once you post it, email your community to let them know. Upvotes can help it make the front page, in which case your API engagement will go through the roof.
  • Slack. Some developers even open up a Slack channel for their customers to ask questions and get instant answers from someone on the dev team. You can use that same channel to let them know about updates.

Give the gift of Beta Access

People love first dibs. The sooner you can tinker with something, the better. Extending beta access to your users will make them feel like an extension of your team. They'll push the API to its limits, and feel compelled to reach out when something goes wrong. Best of all, they'll feel more comfortable giving you feedback on the API in later stages, so that less bugs slip through the cracks.

The folks at Clearbit further incentivize their API users by offering a discount for the service once they fully launch it.

Because we feel like looping your API users into the dev process is instrumental to creating a community, we built our public roadmap. You can also share what you're working on with your users and keep your team accountable for meeting project deadlines.

Make It Easy To Do More

The faster a user can try their hand at your API, the more accessible it is. The obvious benefit is getting more developers integrating your platform. The less obvious benefit is getting each individual developer to go deeper into what's possible with your API.

Work to make the learning curve for your API less steep. That means equip the docs page with plenty of tools that make it quick and hassle-free to get started.

Quickstarts as marketing

As you get to know your API community, you'll get acquainted with all the most popular use cases for your product. Build out Quickstarts to encourage both, existing and potential users to see what the API is capable of.

The Twilio docs even advertise their Quickstarts as “five-to-fifteen minute tours” to make it clear that the time commitment for trying out the product is relatively minimal.

Sandboxing to try before you buy

Developers are curious people, but their curiosity will only take them so far. If they have to rework their dev environment and then go through a complicated authentication process, they're likely to say screw it, and get back to work. But if you set up a sandbox mode, you'll tempt them to pursue that curiosity just a bit further.

Sonar, a tool that lets you Facebook message and SMS your users, has a sandbox that enables you to check out all their most popular calls with relatively little effort.

Like Sonar, you can provide a curl command that devs can just drop into their command line, or, alternatively, you can add an API explorer to your documentation, enabling users to make a call right from the page.

Reputation Is Everything

At the end of the day, you need to have a well-designed well-documented API to maintain a good reputation in the dev community. No bells and whistles will make up for that.

But engaging with your API users will get them invested and excited about your product. Not only will that get them to stick around, but it'll get them to spread the word about your platform and all of its potential.

Stay In-Touch

Want to hear from us about APIs, documentation, DX and what's new at ReadMe?