API Resuability

This use case is about being able to quantify and then incentivize the reuse of APIs across applications, integrations, and automation.

This use case is about being able to quantify and then incentivize the reuse of APIs across applications, integrations, and automation.

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.

Google: Doc

Capability (Page)

This outline describes the capability—or eventually an aggregate capability—to help define and deliver MCP servers using third-party APIs. This capability uses the capability metamodel to shape requirements and provide the context needed for AI integration.

Adapters

There are three capability adapters used to support this use case, with other adapters available.

  • Source Port: HTTP Adapter(s)
  • Artificial Intelligence Port: MCP Adapter
  • Automation Port: OpenAPI Adapter

Use Case

  • Pain

    1. Copilot Leadership Mandate (Cvent)
    2. MCP Leadership Mandate (Ford)
    3. Unmanaged Usage
    4. Unmanaged Spend
    5. Unmanaged API Tokens
    6. Unmanaged Encryption (Ford)
    7. Unmanaged Discovery (Cvent, Ford)

  • Gains

    1. Copilot Source of 3rd-party
    2. 3rd-Party MCP Available
    3. Manage Budget Across
    4. Managed Risk Involved
    5. Optimize SaaS Usage
    6. Create More Visibility (Ford)
    7. Create More Discovery (Ford)
    8. Create More Reusability ([Chase](https://turbo-goggles-5l9zlnj.pages.github.io/docs/targets/chase/))

  • Actor(s)

    1. Architect (Cvent)
    2. Head of API Platform
    3. Head of AI (Ford)
    4. Head of Engineering
    5. Head of Integration
    6. Head of Platform Engineering

Services

These are the services used as part of the capability applied for this use case, but can be expanded as needed to support individual customers, and does not have to include all operations for each service APIs.

OpenAPI is available for all of these APIs, with others available on-demand. Next, we can build a list of which OpenAPI operationId we want to include as the available function list, which can be used by the HTTP adapter to connect to each service.

Engine (Page)

This is the information we are fleshing out about what is needed at the Nafitko Engine level to execute capabilities for this use case. So far, we have the outbound and inbound consumption policies, but should expand to include whatever else needed from the engine metamodel.

Outbound Consumption Policies

  • API Authentication
  • API Token Refresh
  • API Rate Limiting
  • API Pagination
  • API Mocking
  • Session Management

Inbound Consumption Policies

  • Internal Client Authentication
  • Internal Client Authorization
  • Internal Quota Management
  • Internal Rate Limitation
  • Network Management
  • Encryption
  • Session Management

This engine definition is being used to develop content for the website and maintain documentation to support team work, but also eventually customers and the ecosystem. Next we can begin documenting each of the features via our documentation site.

Fabric (Page)

This is the information we need to flesh out what is needed at the Naftiko Fabric level for this use case. Taking our market research and Signals conversations, we can continue to expand and validate this list over time.

  • Discovery (Ford) - Explore and discover services and functions.
  • Spending - Managing the spend across 3rd-party services.
  • Security (Ford) - Managing authentication and encryption across.
  • Change - Managing the changes across any of the services.

We need to eventually validate everything here, and gather anything from other word to help get us closer to something we can talk with Naftiko Signals companies about what they will be paying for in 2027, or even in 2026. Expanding, validating, and shaping our commercial fabric.

Narrative (Cvent, Ford)

This is the narrative to support this use case, taking actual conversation with Naftiko Signals conversations and market research to produce and iterate upon a compelling narrative that we can share with investors, customers, and via other go to market activities.

Title: Leadership Wants to See More Reusability of APIs Using AI Integrations

Body:

References: [Chase]