What is API sprawl?

APIs are sets of rules and protocols that enable software applications to communicate and interact with each other to exchange data, services or functionality. They play a critical role in connecting modern systems and are often a source of revenue for enterprises. 

According to Gartner’s 2024 “Hype Cycle for APIs” report, 82% of respondents say their organization uses APIs internally, and 71% use third-party APIs. Other surveys indicate a majority of all dynamic internet traffic comes from APIs.

API sprawl is often the result of insufficient API management and API governance strategy, and can cause security vulnerabilities, redundancies, developer confusion and unexpected costs. API sprawl is increasingly common, especially in large organizations with multiple divisions. A 2025 Imperva report found that, on average, organizations have 10% to 20% more active APIs than they’re aware of.

Useful as they are, their ubiquity presents an expanded attack surface, and when not properly managed and secured, APIs can pose a security risk. According to SALT’s 2025 Global State of API Security survey, 57% of organizations suffered an API-related data breach in the past two years. Of those, 73% suffered three or more breaches.

API sprawl exacerbates this risk. While a greater number of APIs expands the attack service, it’s not strictly about how many APIs an enterprise uses, and having lots of APIs isn’t inherently bad. It’s the existence of APIs that are unregistered and undocumented that often pose the greatest security risks. According to an Axway survey of technology executives, 78% of organizations do not know exactly how many APIs they currently have.

The average cost of a data breach is USD 4.4 million, but the impact of API sprawl goes beyond immediate revenue losses. API sprawl can also lead to inefficiencies, redundancies, increased development time and dissatisfaction for both internal and external customers.

API sprawl is often a by-product of decentralized development without an overarching API management and governance structure. It can be the result of well-intentioned approaches designed to empower individual teams and embrace agile development. But at scale, this can get messy. The primary causes of API sprawl can be loosely grouped into three categories: organizational, technological and governmental. 

The ways teams are organized and managed can lead to API sprawl. Examples of organizational causes include:

Without a clear process for registering, discovering and retiring APIs, teams often build new APIs without knowing equivalent ones already exist. Over time, an enterprise ends up with dozens of overlapping APIs serving similar purposes—no one knows which is authoritative, which are still maintained, or which are safe to consume.

Platform engineering, which provides developers with self-service platforms for creating APIs, has accelerated in recent years. Gartner reports that 80% of large engineering software organizations will use platforms to provide reusable services by 2026. In addition, more developers work remotely than ever before, which can contribute to isolation and siloed development. Such factors can result in less frequent communication and coordination among teams, creating an environment vulnerable to API sprawl.

In 2025, mergers and acquisitions (M&A) in the technology industry increased 66% year-over-year, according to Morrison Foerster. One of the challenges of mergers and acquisitions is the integration of teams, services and APIs from two distinct organizations. M&A teams are responsible for eliminating redundancies and helping to ensure that the new, integrated system works together as a cohesive whole.  

In recent years, mergers and acquisitions have dramatically accelerated in the AI field; Deloitte notes that in 2025, US software companies spent more on acquiring AI companies than in the previous three years combined. AI agents often require a significant number of APIs to retrieve, analyze and use data and can dramatically increase call frequency in order to operate in real-time.

Without adequate organizational guidance, teams are often left to construct and maintain APIs to their taste—and there are many different flavors of API. Internet of Things (IoT) teams might prefer the real-time communication abilities of gRPC. Teams working on applications that require complex data fetching from multiple resources might prefer GraphQL. Even REST APIs, the most popular architectural style, can be built in several different ways.

In addition, different developers or teams might use different naming conventions, versioning rules or endpoint structures. While the use of different types of APIs isn’t inherently an issue (in fact, it can be a strength—teams should leverage the strengths of different styles and architectures for varying use cases), without shared standards for versioning, naming and cataloging, APIs become hard to discover and reuse. Teams default to building new APIs rather than extending or updating existing ones, directly accelerating sprawl.

Changes in application development and architecture, as well as the nature of modern IT environments can also drive API sprawl.

A microservices architecture, in which a single application is composed of many small, independent components, delivers benefits such as quicker code updates, language flexibility and granular scaling capabilities. But the very nature of microservices means that with each service, additional APIs are introduced to enable inter-service communication. Keeping all these services, and their corresponding APIs, organized and documented can become a challenge.

Applications, services, databases and platforms are often hosted in distributed IT environments, and APIs are often used for data exchange across these various systems and services. There are many benefits of such environments, but more distribution also leads to more APIs, which can lead to sprawl.

Modern DevOps processes use continuous integration and continuous delivery (CI/CD) to support smaller, faster software updates. The frequent updates can result in what’s sometimes known as “version creep.” Developers rush to add new APIs or new versions, rather than evolve existing ones, resulting in a proliferation of undocumented or poorly governed interfaces.

In turn, this can also lead to a proliferation of endpoints, as new versions often introduce new endpoints. This approach prioritizes speed over long-term planning and can lead to sprawl.

Without strong API governance—the set of standards, policies and practices that direct an organization’s use of APIs—the rules of creation, maintenance and deprecation are either poorly enforced or altogether missing. 

API registries provide a centralized catalog of existing enterprise APIs. Without one, APIs (and related information) can be difficult to discover, use and share. This can lead to wasted resources in the development of duplicative services and APIs.

Shadow APIs refer to undocumented or unmanaged APIs operating within an organization without the knowledge or oversight of IT and security teams. Shadow APIs are sometimes set up for tests or to solve small problems, but are not properly catalogued and documented. A 2022 report found that about 31% of malicious transactions targeted shadow APIs, making them a notable security risk.

Sometimes used interchangeably with “shadow API,” a rogue API differs in that it is not simply undocumented; rogue APIs are deployed without authorization and outside of approved governance and security processes.

Zombie APIs are APIs that have been forgotten or abandoned but have yet to be deleted.

API sprawl can cause significant performance, cost and security issues. 

Security weaknesses and data breaches pose significant risks for all types of enterprises, not just those that handle sensitive data, such as healthcare and finance organizations. And APIs and API endpoints are commonly targeted attack vectors. This is particularly true for shadow and zombie APIs that don’t meet enterprise security standards.

To mitigate this risk, it’s vital that enterprises have a comprehensive catalog of all APIs and endpoints, and that APIs and endpoints are sufficiently secured. In a 2024 survey, SALT found that 63% of respondents experienced “security incidents due to unmonitored or inadequately secured APIs.”

The lack of proper visibility, monitoring and an appropriate security standard can make it difficult for IT teams to maintain API security. It’s like having an unlocked window that you don’t even know exists.

API sprawl can contribute to inefficient resource use and increased costs in several ways. For one, there are development and infrastructure costs. When it is difficult for developers to discover internal APIs, they might waste time building a function that already exists. This leaves the organization with two (or more) APIs with overlapping functions, both consuming resources. In addition, there might be gateway and management fees associated with the APIs.

Of course, there are also the developer hours spent building redundant functions. And engineers must spend time discovering, documenting, maintaining and repairing this sprawl—more time away from greater value-driving work. A proper API strategy and acomprehensive API catalog can help eliminate this waste.

Predictable and consistent APIs are the foundation of efficient, well-managed ecosystems.

For example, consider a situation where an API provider uses both “0/1” and “true/false” for Boolean values. Inconsistencies like this can result in miscommunication or incompatibility. This issue can snowball when other layers are involved. Code-generating systems can create broken SDKs if inconsistent specs are inputted, for example. Or inconsistent error response shapes across endpoints can make retries and troubleshooting more difficult.

A shared type registry, along with standardized style guides, rules, and documentation management can help prevent these inconsistencies.

By improving API management and governance, and enterprise development culture more generally (perhaps as part of an API-first or digital transformation strategy), enterprises can both address existing API sprawl and prevent issues moving forward. Common approaches for remediating and preventing sprawl can be roughly grouped into API governance and API management tasks.

Comprehensive and uniformly applied API governance policies can reduce API sprawl and associated risks.

API governance helps enforce enterprise-wide standardization for naming conventions, documentation, security and other facets of API development and management. Such standards help promote interoperability, reduce confusion and minimize security risks.

Governance also provides the policies that direct API lifecycle management. It forces teams to consider questions like, “what is the process of creating and documenting a new API version?” or “when an API goes through the deprecation process, is it retired or deleted?”

API ownership is a vital piece of information that should be clearly listed in an API inventory. Clear ownership helps engineers quickly determine who is responsible for a given API. This clarity simplifies troubleshooting when something goes wrong, helps ensure that governance is enforced, that lifecycle policies are followed (APIs don’t get left to rot, for example) and that any security and compliance gaps are swiftly addressed. 

In an API-first design approach, the API isn’t a by-product or a mere tool: it is the product. API-first contrasts with code-first in that the contract is written before implementation begins, establishing a contract that guides development. While both approaches can produce consistent APIs, prioritizing API design enforces this consistency through a shared design blueprint, enabling parallel development focused on the customer’s perspective.

API-first design acts as a preventive measure against API sprawl by instituting planning, governance and automation to manage an organization’s APIs.

These span both governance and management and could fit in either list. API lifecycle management and API ecosystem management help ensure consistent policy enforcement from design to retirement across all enterprise APIs. These practices establish and enforce clear rules for things like versioning and deprecation, and promote regular audits to consolidate redundant APIs and decommission unused endpoints. They help promote a healthy, optimized and coherent API landscape. 

Automated API testing and security measures can act as “gates” that help ensure that APIs are known, registered and validated before they are deployed. They don’t address sprawl as directly as governance standards, but they serve a gatekeeping function that helps keep sprawl in check by forcing API visibility. 

For example, an organization might build an API registration test into its CI/CD pipeline that checks an API against a centralized repository. An API that is unregistered will not pass through automated pipeline tests and will not be deployed. Of course, this assumes that all deployment teams always follow protocols in the first place, something that can be addressed proactively through API governance and retroactively through automated audits. 

Regular, automatic security and traffic audits can serve a discovery function and help surface previously unknown APIs. For example, traffic audits can detect unexpected API calls and calls to shadow APIs, and security sweeps can discover unregistered endpoints.

An effective management strategy incorporates modern technology and best practices to promote “golden paths” (well-defined, supported approaches) to common API structures and maintain a secure and efficient API environment. 

API discovery is the process of identifying and cataloging all the APIs that an organization uses. Knowing exactly which APIs are available is an important part of preventing redundancy, streamlining workflows and helping software engineers reduce wasted time. However, API discovery is not a simple task; it can be tricky to locate shadow, rogue and zombie APIs. Typically, API discovery is done through a combination of methods, including:

• Traffic analysis
• Manual code review
• Examining existing documentation
• Code repository scans for API endpoints

Many cloud service providers offer API discovery tools within their own platforms, but there are also dedicated third-party scanners and discovery apps. These tools might use automation and AI-powered simulations to probe for undocumented APIs.

API inventories (or catalogs) are centralized repositories that hold information about an organization’s APIs. They serve as a single source of truth for all APIs across their lifecycle. 

API inventories often include the following information:

• API name, indentifier, version number, and API owner
• Description of what the API does
• Base URL and endpoint locations
• Protocol and architectural style
• Authentication method (OpenAPI, for example)
• Link to spec file
• Lifecycle and status information
• Known consumers and dependencies (as well as who can consume it—internal, partner, public)
• Governance and compliance tags (such as GDRP or HIPAA)
• Operational info, such as rate limits and and uptime expectations

Inventories were historically maintained via spreadsheet, which obviously had room for improvement. Modern API catalogs are often accessible through API portals that facilitate API discovery.  

API gateways are a specialized type of middleware that acts as a single entry point for backend APIs. In addition to routing traffic, gateways can be used to enforce consistent authentication, security and management protocols across many APIs.

• Routing: An API gateway receives incoming calls, processes them and routes them to the appropriate backend service(s). The gateway then aggregates the results and supplies one comprehensive response to the API client. This is especially useful in a microservices architecture, where one request might involve many different APIs, but the client wants to receive only one response.
  
  
• Authentication: A gateway verifies the identity of consumers attempting to access an API, using API keys, OAuth tokens, or other security measures
  
  
• Management: API gateways centralize certain management tasks, such as versioning and load management. This enables a more complete view of traffic and other metrics, which can help organizations better monitor API use and performance.