2021 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. One-third stated that it takes one day to one week, and more than one-third stated that it takes one week to one month. A handful of participants indicated that they can deploy in less than a day (or an hour), and another handful take more than a month to complete the process.

There's also some indication that API-first leaders are able to deploy faster—with 17% being able to deploy an API in a day or less (vs 14% of all respondents).

We also asked participants how frequently they deploy APIs to production. The most common response? About one-third stated that they deploy APIs to production between once per week and once per month. Slightly fewer respondents deploy between once per day and once per week, or between once per week and once per month—21% and 28% respectively.

We also found that API-first leaders deploy more frequently, with higher numbers in multiple categories: 9% deploy on a daily basis (vs 6% of all respondents), 27% deploy between once per day and once per week (vs 21% of all respondents), and 36% deploy between once per week and once per month (vs 28% of all respondents).

Next, we asked participants what percentage of their API changes pushed to production experience failure. More than 4 out of 5 developers and API professionals indicated that less than 25% of their changes fail.

API-first leaders were even less likely to experience production failures, with only 13% stating that failures occurred more than a quarter of the time (vs 16% of all respondents).

We asked participants how long it typically takes them to recover when APIs fail, and more than 80% of participants indicated they can recover in less than a day, and fully one-third recover in less than an hour.

API-first leaders indicated that they could recover more quickly, with 46% indicating they could recover in less than an hour (vs 34% of all respondents).

When asked about the obstacles to producing APIs, lack of time is by far the leading obstacle, with 45% of respondents listing it. Complexity was next most frequently cited at 38%, followed by lack of knowledge and lack of people both coming in at 34%.

When asked about the biggest obstacle to consuming APIs, the number one obstacle cited was lack of documentation, clocked at 55%. Other top obstacles to consuming APIs include complexity and lack of knowledge, both cited by one-third or more of participants.

When asked how they collaborate, respondents' top answer (with 50%) was "working with API artifacts on a collaboration platform." Next up, with 40%, was publishing API artifacts to GitLab, GitHub, Bitbucket, etc. Also popular includes sharing URLs to API artifacts (38%), publishing API documentation (33%), and sharing API artifacts to Postman workspaces (32%).

When it comes to preferred change-management practices, versioning APIs scored the most mentions, at 62%. In succession behind that top response, we find utilizing Git repositories (58%), versioning server code (33%), and versioning client code (26%).

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

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 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 (61%), followed by sample code (56%), and standardization (54%). Respondents also indicated that real-world use cases, better workflows, additional tools, and SDKs were helpful, although to a lesser extent than the top responses.