2020 State of the API Report

2020 State Of The API Survey

Executing on APIs

API performance and change

While APIs appear to be perceived as stable and reliable, angst may be rising for when APIs break or change. A significantly higher number of respondents than last year said APIs don't break, stop working, or materially change specification often enough to matter, which was the top response; however, the percentage of respondents who feel APIs still break too frequently also rose significantly versus last year.

Within primary job functions, support engineer was most likely to report that APIs break not enough to matter. Within industries, nonprofits and manufacturing were most likely to report that APIs break not enough to matter. Within functional areas, technical customer support and security were most likely to report that APIs break not enough to matter.

API-first leaders were less likely to report that APIs break too frequently, while respondents with 6+ years of API development experience were more likely to report they break too frequently than those with 0–5 years of experience.

How frequently do APIs break, stop working, or change specification?
Daily
Weekly
Monthly
Too frequently
Not often enough to matter

Obstacles to producing APIs

When asked about the obstacles to producing APIs, lack of time is by far the leading obstacle, with 52.3% of respondents listing it. Lack of knowledge (36.4%) and people (35.1%) were the next highest.

Looking at the top three mentions, API-first leaders were more likely to mention lack of time, lack of knowledge, and lack of people than others. Respondents with 6+ years of API development experience were less likely to mention lack of time, lack of knowledge, and lack of people than those with 0–5 years of experience.

Lack of time: 52.3%
Lack of knowledge: 36.4%
Lack of people: 35.1%
Complexity: 32.7%
Lack of documentation: 31.2%
Stakeholder prioritization: 30.8%
Lack of budget: 24.9%
Stakeholder expectations (unrealistic/unclear): 24.6%
Leadership buy-in: 21.8%
Lack of tools: 15.7%
Team buy-in: 12.3%

Multiple responses allowed

Obstacles to consuming APIs

When asked about the biggest obstacle to consuming APIs, lack of documentation clocked in the highest obstacle to consuming APIs (54.3%), by an extremely wide margin. Other top obstacles to consuming APIs are lack of knowledge, complexity, and lack of time, all cited by a little over one-third of respondents.

Respondents with 6+ years of API development experience were more likely to mention lack of documentation than those with 0–5 years of experience.

Lack of documentation: 54.3%
Lack of knowledge: 35.5%
Complexity: 34.6%
Lack of time: 34.1%
Lack of budget: 21.6%
Lack of people: 19.9%
Leadership buy-in: 18.4%
Stakeholder prioritization: 17.9%
Team buy-in: 13.4%
Lack of tools: 13.3%
Stakeholder expectations (unrealistic/unclear): 13.3%

Multiple responses allowed

Collaborating on APIs

When asked how they collaborate, respondents leaned toward sharing URLs to API artifacts (Swagger, OpenAPI, etc.) which received the highest percentage of mentions at 43.2%. This was followed by publishing those artifacts to GitLab, GitHub, Bitbucket, etc. at 40%. Publishing API documentation to an API portal logged in third-highest at 39.2%.

Instant messaging applications may be ideal for quick communication, but only ranked as the fifth-highest collaboration tool at 28%.

Share URL to API artifacts: 43.2%
Publish API artifacts to GitHub/GitLab/Bitbucket: 40%
Publish API documentation to an API portal: 39.2%
Share API artifacts to workspaces: 33%
Share cURL commands via instant messaging applications: 28%
Email API artifacts: 18.5%

Multiple responses allowed

Change management

When it comes to preferred change-management practices, the utilization of Git repositories scored the most mentions, at 62.9%. Logging in succession behind that top response we find versioning APIs (59%), versioning server code (34.6%), and versioning client code (27.8%). Applying semantic versioning lagged behind at 20.9%.

API-first leaders and respondents with 6+ years of API development experience were more likely to mention each of the top two mentions (i.e., Git repositories and versioning APIs).

Utilize Git repositories: 62.9%
Version APIs: 59%
Version server code: 34.6%
Version client code: 27.8%
Apply semantic versioning: 20.9%
We do not version our APIs: 13.1%

Multiple responses allowed

API testing

When it comes to API testing, a wide variety of practices are applied, although functional testing (70.4%) and integration testing (67.1%) towered over the rest. Performance testing (48.4%) and acceptance testing (42.8%) trailed behind, followed by security testing at 35.8%.

Functional: 70.4%
Integration: 67.1%
Performance: 48.4%
Acceptance: 42.8%
Security: 35.8%
Load: 34.8%
Workflow: 29.4%
Contract: 15.4%

Multiple responses allowed

API documentation

We asked how well APIs are documented, and the results resembled a bell curve, with the highest percentage of respondents (27.7%) indicating that documentation scored a 5 out of 10 (or "OK"). The average score on the 10-point scale was just over 5 (5.06). Only 2.3% of respondents rated APIs they work with "very well documented."

API-first leaders rated documentation of APIs higher on average than others.

0 (Not well documented): 2.1%
1: 4.4%
2: 6.7%
3: 10.2%
4: 11.2%
5 (Documentation is OK): 27.7%
6: 11%
7: 13.1%
8: 9%
9: 2.5%
10 (Very well documented): 2.3%

Mean: 5.06

Improving API documentation

What does it take to improve documentation? Our respondents had insights. The most helpful enhancement API producers can make is to provide better examples in the documentation (66.4%), followed by sample code (62.8%), and standardization (53.0%). API consumers also find real-world use cases, better workflows, additional tools, and SDKs to be helpful, although to a lesser extent.

Better examples: 66.4%
Sample code: 62.8%
Standardization: 53%
Real-world use cases: 51%
Up to date: 31.9%
Better workflow processes: 30%
SDKs: 20.8%
Additional tools: 17.7%

Multiple responses allowed

Meeting expectations—or not

When determining whether an API is—or is not—meeting expectations, API performance (54.9%) and usability of the API (54.8%) were almost inseparable as the top two responses.

API health and/or uptime was not too far behind in third (46.6%). The number of issues reported received mentions from 40.1% of respondents. Somewhat surprisingly, other quantitative measures like the number of applications, services, or programs accessing the API (21%), the number of users accessing the API (15.7%), and revenue generated by the API (10%) all clocked in lower than quality of developer experience (28.8%).

Respondents with 6+ years of API development experience were more likely to mention API performance (the top mention) than those with 0–5 years of experience.

API performance: 54.9%
Usability of the API: 54.8%
API health and/or uptime: 46.6%
Number of issues reported: 40.1%
Quality of developer experiences: 28.8%
Number of calls made to the API: 28.8%
Number of applications services or programs accessing API: 21%
Number of users accessing API: 15.7%
We don't measure whether APIs are meeting expectations: 13.1%
Revenue generated by API: 10%

Multiple responses 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 →