2022 State of the API Report

We asked survey participants how long it typically takes to conceive, implement, test, and deliver an API to a production environment. The results were largely unchanged from last year.

About one-third stated that it takes one day to one week, and another third said it takes one week to one month. A handful of participants said they can complete the process in less than a day (or an hour), and another handful takes more than a month. API-first leaders are faster—with 19% being able to finish the process in a day or less (versus 14% of all respondents).

We also asked participants how frequently they deploy APIs to production. The most common response? A bit more than one-third stated that they deploy APIs to production between once per week and once per month. Almost one-fourth of respondents deploy between once per day and once per week. For API-first leaders, it's more frequent: more than 10% deploy between once per hour and once per day.

Next, we asked participants what percentage of their API changes pushed to production experience failure. Almost half of developers and API professionals said that less than 5% of their changes fail. API-first leaders were even less likely to experience production failures, with 60% stating that failures occur with less than one in 20 deployments.

We asked participants how long it typically takes them to recover when APIs fail. Some 38% said they could recover in less than one hour, an improvement from 34% of respondents last year. And fewer developers than last year indicated they would need a full day. API-first leaders said that they could recover more quickly, with 44% indicating they could be back up in less than an hour (versus 38% of all respondents).

Some 20% of respondents said API security incidents occur at least once a month at their organization, resulting in loss of data, loss of service, abuse, or inappropriate access. While the overall picture was more reassuring—52% said incidents happen less than once a year—the data underscores the importance of shifting left on security and incorporating it early in the API lifecycle.

Interestingly, API-first leaders reported more frequent security incidents, with 25% experiencing incidents at least once a month.

We hypothesize this is because API-first leaders deploy more APIs and have broader visibility of them; in fact, these organizations are twice as likely to deploy APIs daily. As such, they may detect security events that might escape notice at less API-first companies.

When asked about obstacles to consuming APIs, respondents said the number-one hindrance was lack of documentation, chosen by 55%. Other top obstacles to consuming APIs include difficulty in discovering APIs (38%) and lack of knowledge (30%).

API-first leaders, on the whole, were less likely to cite any obstacles–with one exception. They reported greater difficulty reusing APIs or microservices: some 26% of API-first leaders cited this pain point, compared with just 24% for respondents overall.

Lack of time was again organizations' biggest obstacle to producing APIs, followed by lack of people. But the third-biggest hindrance was new this year: lack of API design skills.

A gap in API design skills may be contributing to an overproliferation of microservices, which is a problem in itself. Managing too many APIs or microservices was respondents' sixth biggest obstacle to producing APIs. Among API-first leaders, it's an even bigger problem: too many microservices was their second-biggest obstacle.

When we asked how respondents collaborate, their top answer was working with API artifacts on a collaboration platform (51%). Next up, with 42%, was publishing API artifacts to GitLab, GitHub, Bitbucket, etc.

On the Postman platform in the past year, the percentage of users collaborating doubled as developers and API professionals worked together on collections, APIs, folders, and other entities.

When it comes to preferred change-management practices, versioning APIs again scored the most mentions—just barely—at 62%. Use of Git repositories grew in popularity to 61%, up from 58% last year. Semantic versioning also saw a boost, from 20% last year to 23% this year.

When it comes to API testing, a wide variety of practices are applied, although functional testing (68%) and integration testing (67%) dominated the answers, with no other testing practice coming within ten percentage points of those two choices.

Across the board, almost every practice saw an increase of one to three percentage points from last year, which suggests teams may be expanding their testing methods.

We asked how well APIs are documented, and the results resembled a bell curve, with the highest percentage of respondents (26%) indicating that documentation scored a 5 out of 10 (or “okay”).

Only 3% of respondents rated APIs they work with as “very well documented.”

What would improve documentation? Respondents said the most helpful enhancement API producers can make is to provide up-to-date documentation (57%), followed by code samples (55%) and better examples (53%).