2020 State of the API Report

2020 State Of The API Survey

API Strategies

Internal vs partner vs external

Respondents were asked to allocate 100 points among three API categories (internal, partner, and external) to indicate the percentage of APIs in their organization for each. The percentage of internal APIs (56.96%) increased compared to last year (52.8%), and it's clear that internal APIs are becoming more of a force across the industry. Within primary job functions, full stack developer and mobile developer were most likely to say the largest percentage of their APIs are internal. Within industries, retail, manufacturing, and gaming were most likely to say the largest percentage of their APIs are internal. Within functional areas, DevOps/API Ops and engineering development were most likely to say the largest percentage of their APIs are internal.

API-first leaders were more likely to allocate points to public APIs and less likely to allocate points to internal APIs than those who do not. Respondents with 6+ years of API development experience were less likely to allocate points to public APIs and more likely to allocate points to internal APIs than those with 0–5 years of experience.

Internal (Private only used by your team or your company): 56.96%
Partner (Private shared only with integration partners): 26.75%
External (Public openly available on the web): 16.29%

Factors considered: API integration

When asked what factors are considered before integrating with an API, reliability was the most important factor, at 71.6%, followed closely by security, performance, and documentation, which all came in slightly less (but all above 70%).

Usability and scalability often go hand in hand, and registered similarly at 59.4% and 57.2%, respectively. Pricing registered with fewer than half of respondents, at 47.9%.

Within primary job functions, CXO/VP was most likely to choose reliability as the factor they consider before they integrate with an API. Security engineers were most likely to choose security, while mobile developers and quality engineers were most likely to choose performance. Within industries, healthcare was most likely to choose reliability as the factor they consider before they integrate with an API. Within functional areas, quality assurance/testing and DevOps/API Ops were most likely to choose reliability as the factor they consider before they integrate with an API.

API-first leaders were more likely to choose security, documentation, and performance as factors they consider before integrating with an API than others. Respondents with 6+ years of API development experience were more likely to choose reliability, security, documentation, and performance as factors they consider before integrating with an API than those with 0–5 years of experience.

Reliability: 71.6%
Security: 71%
Performance: 70.9%
Documentation: 70.3%
Scalability: 59.4%
Usability: 57.2%
Pricing: 47.9%
Health/uptime: 41.1%
Changes/versioning: 31.1%
Development community: 30.7%
Provider reputation: 30.6%
Popularity/adoption: 29.9%
Customer support: 29.5%

Multiple responses allowed

Factors considered: producing APIs

When asked what factors individuals consider when deciding to produce an API, a leading factor mentioned by almost 70% of respondents was integration between internal applications, programs, or systems. Integration with or enhancement of current internal or external applications, programs, or systems registered similarly around 61%. Enhancing customer-oriented products or offerings came up with 59% of respondents.

Within primary job functions, full stack developer, technical architect, and backend developer were most likely to choose that integration between internal applications, programs, or systems contributed to their organization deciding to produce an API. Within industries, banking/finance were most likely to choose that integration between internal applications, programs, or systems contributed to their organization deciding to produce an API. Within functional areas, the most noteworthy is that sales/marketing were less likely to choose that integration between internal applications, programs, or systems contributed to their organization deciding to produce an API.

Respondents with 6+ years of API development experience were more likely to choose that integration between internal applications, programs, or systems contributed to their organization deciding to produce an API than those with 0–5 years of experience.

Integration with internal systems: 69.8%
Adding/enhancing functionality of internal systems: 61.3%
Integration with external systems: 61.2%
Adding/enhancing functionality for customers: 59%
Speeding up development: 44.4%
Reducing operation costs: 39.5%
Reducing development costs: 37.5%
Improving testing: 35.7%
Improving organizational security/governance: 34.9%
Enabling mobile applications: 32.5%
Reducing outages/non-performing systems: 26.7%

Multiple responses allowed

Factors considered: consuming APIs

When asked what factors individuals consider when deciding to consume an API, integration with external applications, programs, or systems was the leading factor at 60.1%. Adding or enhancing the functionality of internal applications, programs, or systems was the second-leading factor (57.6%), followed closely by its customer-facing counterpart, adding or enhancing the functionality of products and services offered to customers (56.4%).

Again, pricing and costs did not appear as factors more than 50% of the time: reducing development costs registered at 48.5%, and reducing operating costs at 44.8%.

Within primary job functions, sales/solution engineer was most likely to choose that integration between internal applications, programs, or systems contributed to their organization deciding to consume an API. Within industries, business IT services was most likely to choose that integration between internal applications, programs, or systems contributed to their organization deciding to consume an API.

Respondents with 6+ years of API development experience were also more likely to choose that integration between internal applications, programs, or systems contributed to their organization deciding to consume an API than those with 0–5 years of experience.

Integration with external systems: 60.1%
Adding / enhancing functionality of internal systems: 57.6%
Adding / enhancing functionality for cusomters: 56.4%
Integration with internal systems: 55.6%
Speeding up development: 52.2%
Reducing development costs: 48.5%
Reducing operation costs: 44.8%
Improving organizational security / governance: 32.6%
Improving testing: 32%
Reducing outages / non-performing systems: 26.7%
Enabling mobile applications: 24.8%

Multiple responses allowed

API design

API design is considered early by many respondents: 55.5% shared that API design is considered after stakeholder expectations are set but before development kicks off, and 15.9% even before that point. It is rare for an organization to consider API design last, when the project is almost complete, as only 2.6% reported their organization taking that approach.

Within primary job function, quality engineer was most likely to report that API design is considered early after stakeholder expectations are set. Within industries, banking/finance was most likely to report that API design is considered early. Within functional areas, quality assurance/testing was most likely to report that API design is considered early.

API-first leaders were more likely to consider API design early, and respondents with 6+ years of API development experience were also more likely to consider API design early than those with 0–5 years of experience.

API design is considered first before stakeholder expectations are set: 15.9%
API design is considered early before development kicks off: 55.5%
API design is considered in the middle of projects: 19.4%
API design is considered last when projects are almost complete: 2.6%
Not concerned with API design: 6.5%
Postman logo lockup horizontal. Illustration.

Join API leaders and Postman experts from around the globe at POST/CON 24. Gain new skills through hands-on workshops, in-depth presentations, and conversations about the future of software in an API-first world.