API Reusability

This use case is concerned with encouraging the discoverability and reuse of existing APIs, leveraging existing API infrastructure to quantify what API, schema, and tooling reuse looks like, and incentivizing reuse of APIs and schema across the software development lifecycle—reducing API sprawl and hardening the APIs that already exist.

Teams need to be able to easily use existing API paths and operations as part of new integrations and automation, ensuring that paths, operations, and schema are available within IDE and copilot tooling—meeting developers where they already work. API reusability enables developers while also informing leadership regarding what API reuse looks like and where opportunities to refine exist.

Pain Points

• Teams need to build on existing internal APIs but lack visibility into what’s available
• Reuse of 3rd-party APIs already in use is not tracked or encouraged
• Need to leverage existing OpenAPI specifications but tooling doesn’t surface them effectively
• Organizations do not have a common definition of what API reuse means
• Unable to communicate API reuse metrics to leadership
• Need to incentivize reuse within IDEs and copilots where developers already work

Expected Outcomes

• Leverage existing internal API catalog as foundation for reuse
• Establish API catalog for 3rd-party APIs alongside internal APIs
• Extend existing OpenAPI for MCP delivery
• Communicate reuse metrics to leadership via existing observability dashboards
• Meet developers where they work through IDE and copilot integration

Narrative

A central team has done the hard work to organize all of the internal and public APIs the company produces into a central catalog accessible via portal, API, and Git. The organization is beginning the same effort for 3rd-party APIs like Microsoft Graph, Claude, and Stripe. With this foundation in motion, the focus shifts to understanding and incentivizing the reuse of these APIs across teams and integrations.

With access to internal, public, and 3rd-party APIs established, the organization needs to define what reuse means. Through mapping of the existing API landscape, they can identify the API paths, parameters, headers, schemas, and other common components being used. Aggregating these properties across APIs—beginning with HTTP APIs but expanding from there—requires establishing a common definition of what API reuse means.

Once an initial understanding of API reuse is established across lines of business, domains, and teams, the organization needs an effective way of communicating this across teams and, more importantly, with leadership. Publishing aggregate information about API paths, parameters, headers, schemas, and other properties into existing observability tools provides real-time dashboards for how APIs are being reused or not across the company.

With quantification and communication established, the next step is incentivizing the reuse of internal, public, and 3rd-party APIs across teams. Injecting common patterns needing reuse into existing developer workflows via IDE and copilot—meeting developers where they are—is the most effective approach to incentivizing reuse.

API reuse began as a problem across web and mobile applications, but has grown unmanageable as part of cloud and SaaS integrations. As this problem further explodes because of artificial intelligence, organizations recognize an opportunity to use AI to understand, communicate, and incentivize the reuse of data and APIs. Investing in API reuse saves time and money within months, with benefits continuing to grow over time.