Improve your time to first API call by 20x

The most important API metric is time to first call (TTFC), and having a Postman workspace with collections is crucial to increasing adoption of your API and enhancing developer onboarding.

For developers consuming a new public API, or for new teammates joining your project, Postman Collections are a ubiquitous way for developers to share knowledge about how to work with an API. This blog post walks through quantitative results of what developers already intuitively know—that having a collection enables developers to experience their first successful API call more quickly.

Remove early blockers to smooth technical onboarding

In a recent blog post, “Top 25 API onboarding experiences,” I talked about a faster time to first call equating to faster time to value, which consequently has downstream impacts like higher conversion and retention rates. When technical onboarding includes clear instructions, removing unnecessary manual steps while still providing transparency into what’s happening, new users can achieve their first payoffs and learn while doing it.

Time to first call is the most important API metric
Time to first call is the most important API metric

I asked API publishers to pull the logs or run an experiment and see how long it takes a developer to make their first successful API call. Let’s review those results.

Show me the data

In the following chart, we see it takes 17 minutes to make a successful call with Company A’s API. Developers who use a collection provided by Company A show an improved TTFC of 10 minutes. In other words, developers were 1.7 times faster making their first call when using a collection provided by the API publisher.

 Developers make a successful call 1.7 to 56 times faster when using a forked collection
Developers make a successful call 1.7 to 56 times faster when using a forked collection

The rest of the API publishers in the chart showed even more dramatic improvements to TTFC. These improvements cannot be attributed to the mere presence of documentation. In fact, all of these APIs have API documentation, and some of them have excellent documentation. Instead, the improvements in TTFC can be attributed to the following factors:

  • Formatting the API requests in a way that is quickly executable
  • Presenting the API requests in a way that is familiar to many developers 

Let’s examine why these two factors make such a big difference in TTFC.

Formatting the API requests in a way that is quickly executable abstracts or removes early friction in the developer journey. Even within this small sample of APIs, we see many areas to improve TTFC with a collection.

Providing a collection improves onboarding by providing details about functionality and authorization
Providing a collection improves onboarding by providing details about functionality and authorization

Presenting the API requests in a way that is familiar to many developers reduces the cognitive load in making the first call. Postman is a daily driver for many who work with APIs, so precious time is saved by teaching a new experience in a familiar tool.

Furthermore, more time is saved later in the developer experience because the API call is packaged in a way that can be quickly reproduced in applications and integrations by generating copy-and-paste code samples. If friction, such as authorizing an API call, is too abstracted, new users won’t successfully learn what’s happening and then may struggle when it comes time to integrate more deeply and expand their use case.

Generate a code sample of the API request to integrate into your own applications
Generate a code sample of the API request to integrate into your own applications

How come every API producer doesn’t have a collection?

Most companies with public APIs use Postman Collections even if they aren’t made accessible to their broader developer communities. There are some reasons why teams haven’t shared a collection publicly yet.

  • Competing priorities: Even though creating and sharing a collection is not hard to do, teams are busy with competing priorities and must justify their time and investment with a business case. One of these API producers prioritized sharing a collection after a quarterly survey sent to their partners revealed a Postman Collection was the top request. Another API producer prioritized sharing a collection once they reviewed search terms within their developer portal and saw “Postman Collection” was one of their top search phrases returning zero results.
  • Diffusion of responsibility: For many API producers, there’s no clear responsibility within the organization for developer experience, onboarding, or adoption. For some teams, their public APIs are a neglected part of the product that garners little investment. Sometimes one team cares about API documentation while a separate team cares about usage and usability of their APIs.

If your team requires a business case before getting started on a Postman Collection for your developers, you can show them this blog post. You can also follow the examples shared in this blog post, pull your own logs, run your own experiment, or simply ask your developers if a Postman Collection would be helpful.

Once you’re ready to get started, check out these guidelines and examples of creating great API onboarding experiences. Leave a comment below to share your outcomes, and see how much you can improve your TTFC using a Postman Collection.

What do you think about this topic? Tell us in a comment below.

Comment

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.