Does your API need SDKs
Time to “Hello World” is subpar.
One way to measure developer onboarding success is TTHW or time to “Hello World”. In the world of APIs, we measure how long it takes a developer to perform a key action (create an account, begin a getting started guide, download a starter app) and complete their first API call. Suppose you are only providing API reference documentation. In that case, developers likely spend much time digesting your documentation to understand authentication, error handling, and translating endpoints into code in their preferred language.
High support burden
Your API program offers some base level of support. It could be through traditional support tickets, public forums where questions are posted, or in GitHub repositories as issues. As support teams are a cost center, it’s good practice to measure how many issues are raised in a given period or how long it takes to resolve each issue. Often, support issues can turn into phone calls or even pair programming sessions to solve complex use cases. Engineers may be asked to help, leaving less time to build features. To protect resources and lower the cost of support, you may improve your developer experience with SDKs.
Developers asking for code examples
A more direct signal that developers could benefit from SDKs is seeing tickets or forum posts requesting a solution in a specific programming language. Developers who post these questions have tried independently and, feeling stuck, have turned to you and the community for help. Ideally, a runnable code snippet they can pick apart and learn from.
Community building libraries for your API
Developers in your community who’ve written code to integrate with your API due to no existing SDK may want to help other developers by packaging up their code library and publishing it on GitHub. These community-driven libraries are both a positive signal that developers like your API enough to share their work with others. Still, it’s also a signal there is a gap in your developer experience that the community is trying to fill. We discuss the pros and cons of building an SDK program in our section on engaging community-led SDK projects.
Customers or partners requesting SDKs
Large enterprise customers and strategic partners building to your API may see SDKs as table stakes for integrating. They understand the long-term maintenance cost of writing custom integration code and prefer to use an officially supported library and documentation written for their preferred programming language.
Listen for SDK and library requests from high-value developers. You don’t want to lose the relationship because your API program is seen as not mature enough for their use case.
Competitors offering superior DevX
The API landscape continues to expand, especially for industries like payments, logistics, communications, identity, storage and more. Treat your API like a product and build an experience that helps you win with developers. Are competitors APIs easier to start using? Do they offer SDKs in languages popular with your target audience? Are they building sample apps, tutorials and use case guides based on their SDKs? These could be signals that you need official SDKs to stay competitive.
