API publishers among Postman’s community of more than 15 million are working toward more seamless and integrated developer experiences for their APIs. Distilled from hundreds of one-on-one discussions, I recently shared a study on increasing adoption of an API with a public workspace in Postman. One of the biggest reasons to use a public workspace is to enhance developer onboarding with a faster time to first call (TTFC), the most important metric you’ll need for a public API.
If you are not investing in TTFC as your most important API metric, you are limiting the size of your potential developer base throughout your remaining adoption funnel.
To understand a developer’s journey, let’s first take a look at factors influencing how much time and energy they are willing to invest in learning your technology and making it work.
- Urgency: Is the developer actively searching for a solution to an existing problem? Or did they hear about your technology in passing and have a mild curiosity?
- Constraints: Is the developer trying to meet a deadline? Or do they have unlimited time and budget to explore the possibilities?
- Alternatives: Is the developer required by their organization to use this solution? Or are they choosing from many providers and considering other ways to solve their problem?
Developer journey to an API
With that context in mind, the following stages describe the developer journey of encountering a new API:
Step 1: Browse
A developer browses your website and documentation to figure out what your API offers. Some people gloss over this step, preferring to learn what your tech offers interactively in the next steps. But judgments are formed at this very early stage, likely while comparing your product among alternatives. For example, if your documentation and onboarding process appears comparatively unorganized and riddled with errors, perhaps it is a reflection of your technology.
Step 2: Signup
Signing up for an account is a developer’s first commitment. It signals their intent to do something with your API. Frequently going hand-in-hand with the next step, signing up is required to generate an API key.
Step 3: First API call
Making the first API call is the first payoff a developer receives and is oftentimes when developers begin more deeply understanding how the API fits into their world. Stripe and Algolia embed interactive guides within their developer documentation to enable first API calls. Stripe and Twitter also use Postman public workspaces for interactive onboarding. Since many developers already use Postman, experiencing an API in familiar territory gets them one step closer to implementation.
Step 4: Implementation
Once a developer understands how the API functions, they apply it to their own applications and accommodate their specific use cases. Be careful of artificially hacking a TTFC, perhaps by hiding away the tricky parts or ignoring the gotchas, as you may be shifting the friction to the implementation stage. Productivity shortcuts like SDKs, libraries and code generation can help ease this transition.
Step 5: Usage
Once an API is implemented into production code, a developer decides whether to deepen adoption of your API. They might increase traffic or accommodate other user scenarios. This is when developers take a hard look at latency, responsiveness, flexibility and scalability.
At every stage of this journey, developers learn a little more about your API — what it offers, how it can be implemented and why they should use it over other solutions. A developer’s first API call is the first payoff in the journey that simultaneously shows a developer the what, how and why.
The most important API metric
Time to first call (TTFC) can be the most important API metric, but it’s not the only one. Why is it more important than other metrics, like later-stage usage or performance?
As an API publisher, your API journey may look a little different. But the majority of developers “get it” and “buy in” once they have a chance to interact with an API on their own terms. Legitimately streamlining TTFC results in a larger market potential of better-educated users for the later stages of your developer journey.
You should assess TTFC with both subjective and objective measures. You can measure TTFC subjectively with usability testing and user feedback. You can measure TTFC objectively with web analytics to calculate the time difference between some point of discovery (like a website visit, sign-up or another first contact) and the developer’s first API call.
Measuring smaller increments allows you to be more precise in your attribution. For example, the time a developer spends progressing from browsing to signing up can be attributed to the quality and clarity of your website and documentation. The time a developer spends progressing from signing up to making their first API call can be attributed to the effectiveness of your getting-started guide and product usability. Picking a measure that is too broad makes it harder to accurately attribute the success of your efforts.
If you are not investing in TTFC as your most important API metric, you are limiting the size of your potential developer base throughout your remaining adoption funnel. Even if your market is defined as a limited subset of the developer community, any enhancements you make to TTFC equate to a larger available market.
To learn more about how to use this critical metric, check out how companies including Vonage and Symbl use Postman public workspaces to reduce their time to first call.