APIs are necessarily a communal endeavor — the community fostered between the users, the providers, and those who depend on the API for the functions of their own services drives the development environment of the API space.

Accordingly, developer outreach is absolutely essential for cultivating an API’s network of users and agents. Beyond understanding this importance, figuring out the proper channels, frequency of communication, and methodologies of effective developer outreach can turn a powerful product into an absolute powerhouse.

The Importance of Developer Outreach

First of all, let’s consider specifically why developer outreach is so important. A system is only useful when it’s used — without a group of developers who use a system, that system is essentially isolated, and loses a lot of its potential.

API providers typically face three unique obstacles that inhibit API adoption — Lack of Awareness, Lack of Understanding, and Lack of Vision. Let’s separate each of these, and consider their impact on an API provider.

Lack of Awareness is, simply put, the lack of awareness that a service even exists. How many times has a product been displayed, a solution first encountered, where the average person says “of course, why didn’t I think of that?!” The fact is that most people are unaware of the tool in our hypothetical because they didn’t know they had the problem, and thus had no means to discover the solution.

The same issue comes into play when providing an API. If a developer needs a solution for a complex problem — and they often do — not marketing your API and making others aware of it’s existence is as bad as having no API whatsoever.

Lack of Understanding, however, is a more fickle and possibly damaging beast. While a developer may be aware of an API, if using it seems too daunting it can end a budding relationship extremely fast. Poor error returns, poor documentation, even lack of forum presence can doom an API to the “rejected” pile for the simple reason of “hard to use, no support”.

Finally, Lack of Vision plagues many API providers. This is not to say developers are uncreative, or are unable to envision a product — quite the opposite in fact. This is to say, however, that developer consumers are often unable to envision the product and its usefulness unless clearly identified.

Unanswered questions like “why do I need this?” and “how does this help me?” stem from an API lacking vision, but again, not because the developer lacks the skills to see the possibilities — the API provider has simply provided no example use cases, or functional descriptions in plain english upon which to base this vision of successful implementation.

Thankfully, each of these can be easily rectified using a few basic techniques.

Email, Chat, and Social Media

A joke for the Internet age — a company consults with a firm on how to improve their marketing and sales. The firm asks if they have any significant social media presence. The company scoffs, and says “of course we don’t have an social media presence — we’re the Internet provider!”

It might not be a particularly good joke, but it is insightful — when it comes to business on the internet, many companies still think in the age old “paper and direct sales” mentality. Be professional, directly market, and you’re good to go! That’s not the reality of the modern age, however.

API communities, as with other online spaces, are primarily ones of consuming online resources and communicating in that medium. Accordingly, API developers are some of the most active and prolific users of both email and social media, and not just for “CatFacts” and live tweets about Game of Thrones. API developers use these channels for distributing new services, testing functions and calls, discovering new solutions, and even authenticating with tools.

Failing to have a proper presence online is a surefire way to doom an API provider to obscurity. There are basically two approaches to online presence generation and long-term maintenance. These approaches are forked in two general directions — direct and indirect.

Direct outreach is simply direct communication with interested developers or developers within a stated demographic. Engaging users on email or social media when they have demonstrated an interest in a given solution can inform that the product already exists, and has a responsive team behind it.

This does run a rather significant risk, however — when’s the last time a consumer received a casual cold-call and said “oh, thank you, that’s great, we will absolutely use your service”? The fact is that poorly formed initial discussions and pushy sales methods can do more harm than good, so these relationships should be somewhat casual in nature, framed within the concept of one developer helping another.

The other approach is one of indirect marketing, also referred to as “word of mouth”. Creating a stellar online presence publishing blogs pertaining to the industry, showing new, experimental projects, or even just sharing partners that you think are amazing can do a lot to link the brand of the API provider with the success of the referred products.

Online developer portals should not be an advertisement, but reputable testimonials are definitely helpful when genuine. Offer solutions — post chunks of code you find interesting, or platforms that you think others could use, and tie them into your API, framing it as a “portal to great solutions”. If you open these channels of communication, when developers come looking for solutions, they will find you. When they do arrive at your site, have an instant chat available with your support team.

Outreach is not a one-sided conversation. When you are tweeted at, commented on in YouTube instructional videos, contacted via email, etc., you must respond in a timely, professional manner. Networks live and die by the strength of their individual components — even one poor experience made public can color the way all other developers interact with you.

Event Hosting and Attendance

The API space might be a digital one, but the developers are entirely human. We too often forget that behind every server, behind every terminal, integral to every chunk of API code, there is a living, breathing, unique human, with a range of experiences informing their skill and opinion.

Events, therefore, present a unique opportunity to engage a community in ways that might not otherwise be possible. When we discuss events, what we are really discussing is any event hosted by an API provider where like-minded developers, providers, users, and interested parties can congregate to discuss APIs and API practice.

There are a huge range of potential benefits of hosting an event. First, there is the obvious value-adding experience of attending. Secondly, it helps establish the API provider as a helpful entity seeking to make the industry a better place. More importantly, however, is the opportunity for the API provider to engage in a more direct, personal way with developer users that social media simply cannot match.

Hosting events is also a great way to create an independent, thriving community and knowledge base. Inviting developers to a get together and walking them through common use-cases and solutions tests your product, informs you as to its shortcomings and strengths, and creates in users a direct knowledge of the product. This helps additionally create an inventive and forward-thinking space, allowing space for receiving feedback on your service and visions for improvements.

Keep in mind, however, that these events cannot be just about the API provider — it needs to be a unified community effort. Don’t be the kid that demands everyone come to their birthday party with presents, and then is mysteriously never around for anyone else’s.

Documentation and Knowledge Bases

Documentation will set you free. That simple phrase has guided more than its fair share of developers, and it rings truer as the systems that drive this crazy and beautiful interconnected information superhighway become ever more complex.

The quickest way, therefore, for an API provider to fail in attracting developers is a lack of documentation and knowledge provision for their services. Failing to document the core functionality is a nail in the coffin for the grave dug by the API provider — but even failing to offer user-friendly documentation can gradually add the dirt over your head.

There are two trains of thought on documentation, however, which run in stark contrast to one another. One is the idea that documentation must be done directly and through the efforts of the developer creating the system itself; the end-all-be-all documentation.

While this certainly adds a great deal of control over the resultant documentation and the community that uses it, it has some drawbacks. The first and most prominent is the added stress upon the API provider. While basic documentation is a core requirement, documenting every solution to every problem that might or might not arise in an infinite number of situations is daunting, and borderline impossible.

Just as important is the fact that documentation from the developer will often come from those who wrote the code, and at time, can be too technical in nature; API documentation must provide both machine and human readability. While having good error reporting, syntax, style constraints, and documentation codes can do a lot to help in this regard, it does create a sizable information load to maintain.

The second train of thought is establishing a user-centric knowledge base. Creating a database where users can tag issues, perhaps in ticket form or even a wiki-like interface, allows users themselves to document and highlight new issues, as well as suggest their solutions, for future users.

User-base generated documentation is by nature very human-readable. There is of course a huge caveat. Repeat the following — knowledge bases do not replace human contact. Too many corporate databases exist documenting issues found on APIs, operating systems, and applications that terminate with a generic answer — this is a failure in communication.

When a user finds a knowledge base article, the best hope is that it answers their question and gives an easy solution. If it does not, however, terminating at the article and replacing your social media presence with this simple article or ticket can doom an API faster than anything else.

Remember — knowledge bases should augment and support email, forums, and social media, not replace them.

Conclusion

These basic techniques and approaches should comprise 99% of most API provider’s strategies when it comes to fostering unparalleled developer outreach. While some of it seems common sense, many would be surprised at just how common and epic these failures in basic outreach are across the industry. Adapting these solutions will provide the leverage that API providers need to succeed, catapulting initial success and goodwill to a new, higher plane.