2022 State of the API Report

Postman State Of The API Report Postmanauts researching ontop of graphs. Illustration.

Executing on APIs

Time to production

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).

Less than one hour: 4%
Less than one day: 10%
Between one day and one week: 34%
Between one week and one month: 34%
Between one month and six months: 15%
More than six months: 2%

Due to rounding, percentages may not add up to 100%.

Deployment frequency

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.

Once per hour to once per day: 6%
Once per day to once per week: 22%
Once per week to once per month: 35%
Once per month to once every six months: 26%
Fewer than once every six months: 11%

Due to rounding, percentages may not add up to 100%.

For us, it's about going from ideation to working software as quickly as possible, and producing artifacts that resemble working software.

Doug R., platform architect

Deployment failures

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.

Less than 5% of the time: 49%
5% - 10% of the time: 29%
11% - 25% of the time: 14%
26% - 50% of the time: 6%
More than 50% of the time: 2%

Due to rounding, percentages may not add up to 100%.

Time to recovery

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).

Between one hour and one day: 46%
In less than one hour: 38%
Between one day and one week: 12%
Between one week and one month: 3%
More than one month: 1%

Due to rounding, percentages may not add up to 100%.

Frequency of API security incidents

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.

Less often than yearly: 52%
Quarterly: 11%
Monthly: 10%
Yearly: 8%
Weekly: 7%
Twice a year: 7%
Daily: 4%

Due to rounding, percentages may not add up to 100%.

Obstacles to consuming APIs

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 documentation: 55%
Difficulty in discovering APIs: 38%
Lack of knowledge: 30%
Lack of time: 29%
Difficulty reusing APIs or microservices: 24%
Lack of people: 24%
Lack of budget: 21%
Organizational buy-in or alignment: 19%
Lack of tools: 16%
Other: 2%

Multiple choices allowed

Obstacles to producing APIs: lack of design skills

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.

Lack of time: 44%
Lack of people: 38%
Lack of API design skills: 34%
Lack of documentation: 33%
Lack of knowledge: 28%
Managing too many APIs or microservices: 28%
Lack of budget: 22%
Difficulty in discovering supporting APIs: 20%
Organizational buy-in or alignment: 19%
Lack of tools: 16%
Other: 2%

Multiple choices allowed

Collaborating on APIs

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.

Work with API artifacts on a collaboration platform (e.g. Postman): 51%
Publish API artifacts (i.e. Swagger OpenAPI) to GitHub/GitLab/Bitbucket: 42%
Share URL to API artifacts (i.e. Swagger OpenAPI): 39%
Publish API documentation to an API portal: 33%
Share API artifacts (i.e. Swagger OpenAPI) to workspaces: 33%
Share cURL commands via instant messaging applications: 22%
Email API artifact (e.g. Swagger OpenAPI): 17%
Other: 3%

Multiple choices allowed

Change management

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.

Version APIs: 62%
Utilize Git repositories: 61%
Version server code: 35%
Version client code: 27%
Apply semantic versioning: 23%
We do not version our APIs: 11%
Other: 1%

Multiple choices allowed

API testing

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.

Functional: 68%
Integration: 67%
Performance: 54%
Security: 47%
Acceptance: 43%
Load: 36%
Workflow: 35%
Contract: 17%
We do not test our APIs: 4%
Other: 1%

Multiple choices allowed

API documentation

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.”

0: 2%
1: 4%
2: 6%
3: 10%
4: 11%
5: 26%
6: 11%
7: 13%
8: 10%
9: 3%
10: 3%

Due to rounding, percentages may not add up to 100%.

Improving API documentation

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%).

Up-to-date documentation: 57%
Code samples: 55%
Better examples: 53%
Standardized documentation: 51%
Real-world use cases: 45%
Better documentation workflow: 44%
Try it/interactive documentation: 41%
SDKs: 20%
Other: 2%
Additional tools: 1%

Multiple choices allowed