Introduction

According to Gartner, the average enterprise spends 30–40% of its IT budget simply managing the complexity created by unintegrated applications. Every new system, storefront, or third-party service adds another API to maintain, secure, and document and that overhead compounds faster than most technology roadmaps account for.

Adobe App Builder’s API Mesh is built to reverse that trend: instead of every client application calling a dozen different APIs directly, API Mesh consolidates them behind a single, managed endpoint. This blog explains what API Mesh is, how it works, what it takes to stand one up, and where it delivers the most value for enterprises running composable commerce and experience platforms.

Why Do Fragmented APIs Quietly Drain IT Budgets?

Most enterprises don’t have one API problem they have dozens of small ones. A typical digital platform pulls data from internal services, third-party vendors, and legacy systems, each with its own authentication method, response format, and versioning schedule. Every client application that needs data from more than one of these sources ends up writing (and maintaining) custom logic just to stitch the responses together.

This is exactly the sprawl Gartner points to when it puts unintegrated-application overhead at 30–40% of IT spend. It isn’t one large, visible cost it’s dozens of small ones: duplicate authentication logic, inconsistent error handling, and engineering time spent on integration plumbing instead of features that move the business forward.

Summary: API sprawl not any single system is what drives up integration cost; each additional unmanaged API adds duplicated engineering overhead.

What Is API Mesh, and How Does It Simplify Integration?

API Mesh is best understood as an API broker: a layer that combines multiple backend APIs into a single, unified endpoint that client applications call instead of reaching out to each service individually. It’s particularly well-suited to microservices architectures, where the number of individual services and the operational cost of managing them one by one tends to grow quickly.

Conceptually, an API Mesh implementation has four parts:

• Client application: The web app, mobile app, or storefront that needs data from multiple sources.
• API Mesh gateway: A single point of entry for all API requests across the organization, responsible for routing and transforming requests and responses.
• Resolvers: The logic layer that shapes each request into the format a specific backend API expects, and shapes the response back into a consistent format for the client.
• Backend APIs: The actual services being called internal systems, third-party vendors, or any mix of the two.

Instead of a client application needing to know the address, format, and authentication method of every backend service, it talks to one gateway, and the mesh handles the rest.

Summary: API Mesh acts as a single gateway that consolidates multiple backend APIs, so client applications no longer need to integrate with each one directly.

How Does an API Mesh Actually Handle a Request?

The request flow is straightforward once the mesh is configured:

1. A client application sends a request to the API Mesh gateway.
2. The gateway routes the request to the correct resolver based on the path and method requested.
3. The resolver rewrites the request into the format the target backend API expects, and forwards it.
4. The backend API processes the request and returns a response.
5. The resolver transforms that response into a consistent format, and the gateway returns it to the client.

The client application never has to know which backend system actually served the data, or in what format that system natively responds. That abstraction is what makes it possible to swap out or upgrade a backend service later without rewriting every client application that depends on it.

Summary: Every request passes through one gateway and resolver layer, which standardizes formats and hides backend complexity from client applications.

What Does It Take to Stand One Up?

Implementing API Mesh doesn’t require replacing existing systems it’s a configuration exercise layered on top of what’s already there. At a high level, the process involves:

• Setting up the environment: Creating a project in the Adobe Developer Console and provisioning access to Adobe I/O, the platform API Mesh runs on.
• Adding API Mesh to the project: Attaching the API Mesh service to the relevant workspace within that project.
• Defining the mesh configuration: Specifying which backend services and endpoints should be exposed through the mesh, and how requests and responses should be transformed for each one. This is done through a structured configuration file rather than custom integration code per service.
• Securing access: Managing authentication centrally typically API keys for internal or trusted consumers, and OAuth2 for services that need stronger authorization guarantees, especially those exposed beyond an internal network.

Because this is configuration-driven rather than code-per-integration, adding a new backend service to the mesh is a much smaller lift than building a new point-to-point integration from scratch and every service benefits from the same centralized authentication, routing, and error-handling logic.

Summary: Standing up an API Mesh is primarily a configuration exercise on Adobe’s existing developer platform, not a rebuild of existing systems.

Where Does This Deliver the Most Value for Enterprises?

API Mesh pays off most clearly in three areas:

• Reduced integration overhead: New client applications and features can consume existing backend services through the mesh, instead of engineering teams rebuilding integration logic every time.
• Consistent governance: Authentication, error handling, and request/response transformation are enforced centrally, rather than left to individual teams to implement (and maintain) differently across projects.
• Flexibility to evolve backend systems: Because client applications talk to the mesh, not directly to backend services, a backend system can be replaced, upgraded, or re-platformed without requiring every consuming application to change at the same time.

At Bajaj Tech.AI, we use API Mesh when building composable commerce and experience platforms particularly where a storefront needs to pull from commerce, content, and third-party services simultaneously. Consolidating those calls behind one secured, well-governed endpoint is consistently one of the fastest ways to cut both integration timelines and ongoing maintenance load for our clients.

Summary: The biggest returns from API Mesh come from lower integration overhead, centralized governance, and the flexibility to change backend systems without breaking client applications.

Key Takeaways

• Unintegrated, point-to-point APIs are a hidden but significant cost center Gartner puts the IT budget impact at 30–40% for enterprises with fragmented application landscapes.
• API Mesh consolidates multiple backend APIs behind a single gateway, so client applications integrate once instead of repeatedly.
• Standing up a mesh is a configuration exercise on Adobe’s developer platform, not a rebuild of existing backend systems.
• Centralizing authentication and request/response transformation reduces both integration time and long-term maintenance burden.
• Because client applications never talk to backend systems directly, those systems can be upgraded or replaced with minimal disruption to the applications consuming them.

Conclusion

API sprawl is one of the most underestimated line items in enterprise IT spending, and it only grows as organizations add more storefronts, services, and third-party integrations. API Mesh addresses this at the architecture level rather than asking every team to solve it independently consolidating access, standardizing governance, and giving enterprises room to evolve their backend systems without disrupting the applications built on top of them. For organizations already running composable commerce or experience platforms on Adobe, it’s one of the more immediate wins available.

Dealing with API sprawl across your platforms? Connect with our experts to design an integration architecture built to scale.