What Is API Sprawl and Why Is It Important?

APIs are at the heart of a lot that goes on in our daily lives, but as API growth skyrockets, sprawl issues are beginning to emerge.

More and more microservices are being developed to enable what Gartner calls the composable enterprise. For instance, the 2022 State of APIs report from Rapid discovered that large companies with 10,000 or more employees tend to have over 250 internal APIs. APIs are also pivotal to new SaaS products and partner ecosystems. Yet not all these integration touchpoints are being carefully managed.

Recently, two new risks, improper inventory management and unsafe consumption of APIs, were added to OWASP’s foundational list of top 10 API security risks. To me, this reflects increasing challenges in maintaining an accurate overview of an organization’s API footprint and the increasing risks inherent in blindly integrating third-party APIs. And, if not managed appropriately, the sudden growth of generative AI-related tools and APIs could exacerbate existing technical debt.

Addressing API sprawl is vital because a lack of consistency could slow down development timelines. Additionally, without governance and visibility into their life cycles, APIs are more prone to having access-control risks or turning into zombie endpoints. Let’s explore what API sprawl is and why addressing it is important. I’ll also leave technical leaders with some tips on how to avoid it in their development culture.

Defining API Sprawl

EON Consulting describes technology sprawl as “the uncontrolled expansion of various technologies — be it software, hardware or cloud services — within an organization.” To a certain degree, technical debt is inevitable due to increasing reliance on digital technologies. But, when growth really begins to get out of hand, you start to encounter adverse effects. That’s sprawl.

In terms of APIs, I see sprawl as a haphazard adoption of API-first strategies without properly adopting industry standards or having a vision for how these interfaces are supported for the long haul. Many large organizations are dealing with a ballooning API portfolio composed of various development protocols and design styles. They’re also likely juggling different versions and varying release and deprecation timelines. This can create a spaghetti network of integrations, which tend to break often.

The main contributor to sprawl is simply the sheer number of APIs being developed — F5 estimates that nearly 200 million APIs exist today. Another factor is that not all APIs are documented. In fact, only 10% of organizations fully document their APIs, according to a 2023 report from Enterprise Management Associates. This means tribal knowledge often goes out the door with developer churn.

The Negative Impacts of API Sprawl

Not appropriately overseeing your API inventory can come back to bite you. For instance, it can decrease discoverability and hinder technical reusability. A lack of documentation and design forethought can limit usability. A lack of governance can lead to more dire security consequences, such as forgotten, unmaintained endpoints.

Decreased Developer Experience

Inconsistencies between APIs can stunt the developer experience around integration. For example, many different design paradigms are used in modern API development, including SOAP, REST, gRPC and more asynchronous formats like webhooks or Kafka streams. An organization might adopt various styles simultaneously.

Using various API styles provides best-of-breed options for the task at hand. That said, style inconsistencies can make it challenging for a single developer to navigate disparate components without guidance. A lack of documentation can especially be bad if you are externalizing APIs to partners or productizing them as public services. Quality developer experience is not just a competitive advantage in the tech market, but it is quickly becoming an expectation.

Security Vulnerabilities

As cybersecurity experts often say, you can’t secure what you don’t know. Amid technology sprawl, you likely won’t be aware of the hundreds, if not thousands, of APIs being developed and consumed daily. Without inventory management, APIs can slip under the rug and rot.

API sprawl can also lead to insecure coding practices. Security researchers at Escape recently found 18,000 high-risk API-related secrets and tokens after performing a scan of the web. Leaving such credentials exposed risks them being used for targeted attacks on corporate systems, which can lead to breaches that diminish consumer confidence and costly fines.

Poor Life Cycle Management

Life cycle management can also suffer with sprawl. If API versioning and retirement schedules aren’t communicated effectively, it can easily lead to breaking changes on the client side. This could have cascading effects when multiple APIs depend on one another, creating a fractured ecosystem.

In general, API sprawl can result in a more chaotic development culture. And it’s not just a concern for IT. API sprawl can also hurt the business. For instance, hastily acquired shadow APIs might not fit into a broader IT strategy. There may be hidden costs within inefficient designs or resources lost in duplicative work. Broken clients could mean a loss of end-user functionality leading to a decline in revenue.

Ideas to Manage API Sprawl

That’s a lot of potential detrimental outcomes of API sprawl. So, how can we avoid this mess? Here are some techniques that developers, architects and the CTO can align on to make their API strategies safer, leaner and more usable:

• Keep documentation up to date. Stress the importance of API documentation. All APIs developed internally should be documented fully. Ideally, this documentation includes human-readable descriptions and sample code to help others understand their inner workings.
• Maintain an inventory of all your APIs. Beyond documenting each API individually, audit your surface area and create a catalog of all the APIs your organization has constructed or is consuming from third parties. This information could be added to a preexisting internal developer platform (IDP), for example.
• Coalesce around OpenAPI Specification. OpenAPI Specification (formerly Swagger) has become the de facto industry-standard specification for describing web APIs. Adopting specification-driven API development can unlock solutions to many of the issues mentioned above.
• Develop an internal API-design style guide. Just like an editorial team has a style guide for written copy, software development would benefit from a style guide outlining internal API conventions. Setting guardrails for internal development standards can take the guesswork out of API design and make the process of consuming APIs easier. Check out the API Stylebook for some concrete examples.
• Follow security best practices. Bake in the proper security controls from Day 1 for all API development. This includes API security best practices like using an API gateway, adopting OAuth and OpenID Connect, applying multifactor authentication and following safe token-handling practices. It’s also a good idea to adopt a zero trust model and follow the rule of least privilege when assigning API access scopes.
• Automate governance when possible. Design reviews are cumbersome, and IT governance shouldn’t get in the way of innovation. Automated testing could be adopted to shift this left, enabling the best of both worlds. For example, API management vendors have created many free tools for assessing the design and security of API specifications, like RateMyOpenAPI, API Insights and OpenAPI.security. Spectral is also a unique open source tool that can lint an OpenAPI definition file against custom rules.
• Consider other machine-readable specifications. OpenAPI is helpful for areas like documentation and SDK generation. However, it leaves out some valuable business data. APIs.json is an interesting emerging standard that could help improve the discoverability of API operations and metadata.

Taking a Long-Term API Platform View

API adoption is growing considerably, and many companies want to participate in the blossoming API ecosystem. Undoubtedly, the ongoing AI wave will bring new APIs to market, enabling some exciting possibilities for all engineers. At the same time, APIs are not hobbyist projects anymore. They deserve careful attention.

Unmitigated API sprawl can bring negative consequences that could exacerbate insecure coding practices. Therefore, it will be important to respond to API sprawl by keeping an inventory of all services and establishing more of a documentation-driven culture. API-first isn’t going away anytime soon, so internal standards should be set for the long term — hopefully before things get out of control.

As a side note, it will be interesting to see how new platform engineering initiatives consider the role of APIs. For some time, developers have been expected to oversee not only programming but the deployment and maintenance of their software. In the wake of technology sprawl, the industry appears to be shifting back toward a bit more centralized control. This presents an opportunity to regain standards and set a “paved road” for common developer workflows, including API design and management.