Established thinking in large organisations has been to focus API reuse goals and metrics on internal, in-house produced APIs. The logic is straightforward: build once, reuse everywhere, and maximise the return on investment for internally developed services.

However, recent insights suggest we've been looking at API reuse through the wrong lens. The real opportunity—and the real risks—lie not in producer-side reuse, but in how we enable engineers to consume our and third-party APIs efficiently, securely, and with proper governance.

Case study

Veronica heads up the API product management capability at a globally recognised financial institution. She has established API management and governance practices that provide visibility, incentive models, and security controls around internal API use and reuse.

Teams across the organisation have been experimenting with AI in a myriad of use cases such as: supporting greater developer productivity, creating user customer journey experiences, automating processes and redesigning workflows. Most of these scenarios involve consuming third party APIs.

Veronica is now wrestling with a new dynamic for API governance. How do they get visibility of what’s going on today? How can they incentivise colleagues to know about and then (re)use approved third party APIs? What are the expectations on adjacent teams such as Security, Risk and Compliance, or Finance, to support new practices? How will any changes in practice be communicated and maintained?

The Traditional View: Producer-Side Reuse

Traditionally, API reuse has been framed as a producer play. Organisations track metrics like how many times an internal API endpoint is called, how many teams leverage a particular service, or how much duplication exists across internal APIs. The goal has been to identify opportunities for consolidation and standardisation amongst internally produced services.

Whilst this approach has merit, it misses a critical dimension of modern software development.

Today's applications rarely rely on internal APIs alone. Instead, they integrate dozens—sometimes hundreds—of third-party services, from payment processors to AI models, from mapping services to authentication providers.

The Real Opportunity: Consumer-Side Reuse and Governance

The conversation shifts dramatically when we reframe API reuse as a consumer play rather than a producer play.

From this perspective, the question isn't "How many times are our internal APIs reused?" but rather "How effectively are our engineers consuming external APIs, and what visibility and control do we have over this consumption?".

Consider a typical enterprise scenario: a VP of Product Management seeks reuse statistics for approximately 100 APIs used with partners. They want to understand not just what's being used, but how paths and schemas are being reused across different contexts. This visibility becomes crucial for several reasons:

• Cost management: Third-party API calls often come with direct costs. Without visibility into consumption patterns, organisations can face unexpected bills.
• Security and compliance: Shadow IT in the API space means teams are integrating services without proper security review or compliance checks.
• Developer productivity: When multiple teams integrate the same third-party service independently, they duplicate effort and miss opportunities for shared learning.

Why We've Neglected Third-Party API Governance

Three key factors have prevented organisations from properly addressing third-party API consumption:

1. Shadow IT Complexity

Much of third-party API consumption happens in the shadows. Individual developers or teams integrate services directly, often using their own API keys, without going through centralised procurement or architecture review. This decentralisation makes it nearly impossible to get a comprehensive view of what's being used and how.

2. Misperception of Risk

Organisations have historically focused governance efforts on internally produced APIs for obvious reasons. It’s where risks are visible and, with the right approach, are measurable and governable.

However, third-party API consumption carries significant risks: data leakage to external parties; dependency on services with unknown SLAs; security vulnerabilities in how credentials are managed; and the associated cumulative costs that can spiral out of control.

3. Investment Management Motivation

Any savings on internal systems integration have a direct financial advantage on an organisation’s overall investments in tech-related change.

Large enterprises with complex tech application and development stacks that include many legacy systems and third party or SaaS applications, expect to have to spend 30 to 60% of discretionary IT investment on integration.

The case for simplifying integration is unambiguous. Less time spent on integration, more customer or user features per dollar invested.

The less time and energy spent on integration, the more available to spend on AI, the overriding motivation and justification for today’s business environment. Across all industry sectors and technology use cases.

The MCP Moment: A Burning Platform for Change

The emergence of Model Context Protocol (MCP) and similar technologies creates what might be called a "burning platform" moment for API governance. As engineers increasingly rely on AI-assisted development and third-party service integration becomes even more frictionless, the need for visibility and governance becomes urgent.

The opportunity now exists to inject third-party API catalogues directly into developer tooling, making it as easy for engineers to discover approved, governed third-party services as it is to find internal APIs. This shifts the conversation from restriction to enablement—providing engineers with a clear path to consume external services whilst maintaining the visibility and control organisations need.

A New Framework: The Abstraction Layer Approach

Rather than trying to prevent third-party API usage or retroactively tracking it, organisations should consider implementing an abstraction layer from the producer perspective. This means:

• Creating a unified catalogue of approved third-party services
• Providing centralised credential management and usage tracking
• Publishing reuse metrics to monitoring tools like Datadog and documentation platforms like Notion
• Making this catalogue available directly within developer toolchains via MCP or similar protocols

This approach acknowledges the reality of modern development whilst providing the governance and visibility organisations need. It's not about solving reuse in the traditional duplication-avoidance sense, but about making third-party service consumption visible, governed, and optimised.

Conclusion: Visibility for Internal Developers

The future of API reuse isn't about counting how many teams use your internal user service. It's about ensuring that when developers need to integrate a payment processor, a mapping service, or an AI model, they can do so with full visibility into what's already approved, how others are using it, and what the cost and security implications are.

This is particularly relevant for private, internal developers whose domain is the organisation itself. By providing them with proper tooling and governance for third-party API consumption, organisations can reduce costs, improve security, and increase developer productivity—all whilst enabling the innovation that comes from leveraging the broader API economy.

We've been wrong about API reuse all along. The real opportunity isn't in optimising what we build, but in governing and simplifying what we consume.