2023 State of the API Report

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

SOTA hex

Executing on APIs

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.

Some industries were faster at producing APIs than others. In education, 18% of respondents said they required a day or less. In financial services, only 11% of survey-takers said the same.

Less than 1 hour: 4%
Less than 1 day: 10%
Between 1 day and 1 week: 32%
Between 1 week and 1 month: 35%
Between 1 month and 6 months: 16%
More than 6 months: 2%

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

We also asked participants how frequently they deploy APIs to production. The most common response? One-third said they deploy between once a week and once a month.

Just 6% of respondents deployed between once per hour and once per day. But among API-first leaders, the percentage was higher: 10% deploy that frequently.

Between once per hour and once per day: 6%
Between once per day and once per week: 22%
Between once per week and once per month: 33%
Between once per month and once every six months: 27%
Fewer than once every six months: 12%

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

How often do API changes fail when pushed to production? Not often. Fewer than one in 20 API changes fails, according to half of respondents.

Healthcare claimed the best failure rate, with 55% of respondents stating that fewer than one in 20 API deployments failed. Education was at the other end of the spectrum; only 43% of respondents there said their failure rate was that good.

API-first leaders were less likely to encounter failures than all respondents, with 60% stating that failures occurred less than one time in 20.

API-first leaders
All respondents

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

When an API fails, how quickly can it typically be restored? We're happy to say that this figure has improved steadily over the years. Today, 41% say they can restore the API in less than one hour. That's an improvement from 38% last year and 34% the year before that.

API-first leaders reported the fastest recovery times: 53% indicated they could be back up in less than an hour.

API-first leaders
All respondents

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

In 2023, global survey-takers reported fewer API-related security events: 56% said incidents happen less than once a year, an improvement on last year's 52%.

When we break out the results by country, we see some stark differences. Incidents were rarest in the U.S., with 67% of respondents saying API security events occur less than once a year.

In Europe, the Middle East, and Africa, only 57% of respondents could make that claim. In the Asia-Pacific and Latin America, the figure was lower still, with only 47% saying API security events happened less than once a year.

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

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

We asked respondents to identify which API security risks posed the greatest concern for their organization.

Their top choice was “Improper authentication, authorization, or access control,” cited by an almost two-to-one margin over other risks.

CEOs, CTOs, and developers were aligned on this view, with about 30% of each group acknowledging it as a key hazard. But some job roles were less likely to recognize improper access as a key risk: just 21% of product VPs and 26% of data engineers/analysts cited it as a top concern.

Improper authentication authorization or access control: 30%
Insecure data leaks or exposure: 17%
Business-logic issues: 16%
Insufficient logging and monitoring: 12%
Inadequate access control: 8%
DoS attacks: 8%
Injection attacks: 5%
We don't know where all our APIs are: 3%

Multiple choices allowed.

The greatest security risk? Humans. Always the largest attack vector.

Survey Respondent

When we asked about obstacles to consuming APIs, 52% of respondents said lack of documentation was the biggest problem. Other top barriers included difficulty discovering APIs (32%) and lack of time (27%).

API-first leaders, on the whole, were less likely to cite any obstacles to consuming APIs—with one exception. They were more likely to mention difficulty reusing APIs or microservices. Twenty-one percent of API-first leaders cited this pain point, compared with just 19% of respondents overall.

Lack of documentation: 52%
Difficulty in discovering APIs: 32%
Lack of time: 28%
Lack of knowledge: 27%
Lack of budget: 23%
Lack of people: 22%
Difficulty reusing APIs or microservices: 19%
Organizational buy-in or alignment: 18%
Lack of tools: 13%

Multiple choices allowed.

In this year's survey, a lack of time and people were again named as the biggest obstacles to producing APIs.

But when we filtered by large companies with over 5,000 developers, a different top problem emerged. Respondents at these mega-companies cited a lack of API design skills as the biggest obstacle to producing APIs.

Interestingly, respondents at these large companies were also more likely to say that “Managing too many APIs or microservices” was an obstacle to producing APIs. Thirty-one percent of these respondents said so, compared with just 23% of all survey.

It's possible the lack of API design skills is making it more difficult to manage APIs and microservices at the largest companies.

Lack of time: 43%
Lack of people: 37%
Lack of API design skills: 32%
Lack of documentation: 29%
Lack of knowledge: 25%
Lack of budget: 24%
Managing too many APIs or microservices: 23%
Organizational buy-in or alignment: 18%
Difficulty in discovering supporting APIs: 15%
Lack of tools: 14%

Multiple choices allowed.

When we asked respondents to cite the different ways they collaborate on APIs, their most common answer was working with API artifacts on a collaboration platform such as Postman (50%). Next up was publishing API artifacts to GitLab, GitHub, or Bitbucket, which was chosen by 39% of respondents.

Work with API artifacts on a collaboration platform (e.g. Postman): 50%
Publish API artifacts (e.g. Swagger OpenAPI) to GitHub/GitLab/Bitbucket: 39%
Share URL to API artifacts (e.g. Swagger OpenAPI): 36%
Publish API documentation to an API portal: 32%
Share API artifacts (e.g. Swagger OpenAPI) to workspaces: 30%
Share cURL commands via instant messaging applications: 21%
Email API artifacts (e.g. Swagger OpenAPI): 15%

Multiple choices allowed.

When it comes to change-management practices, there was a new preferred method: using Git repositories. This practice earned the most mentions in 2023, just edging out versioning APIs, which was the most popular choice in the previous two years.

Utilize Git repositories: 61%
Version APIs: 60%
Version server code: 34%
Version client code: 25%
Apply semantic versioning: 23%
We do not version our APIs: 11%

Multiple choices allowed.

When it comes to API testing, users employed a wide variety of practices, although functional testing (67%) and integration testing (64%) dominated the answers. No other testing practice came within 10 percentage points of those two choices.

As in prior years, one in 25 respondents said their team doesn't test its APIs.

Functional: 67%
Integration: 64%
Performance: 51%
Security: 46%
Acceptance: 41%
Load: 34%
Workflow: 33%
Contract: 16%
We do not test our APIs: 4%

Multiple choices allowed.

Postman v11 is here!

It's jam-packed with updates to help you collaborate on your APIs, augment yourself with AI, and more.

See what's inside v11 →