API Mesh for Adobe Commerce: Combining Commerce, PIM and CMS in One API

API Mesh for Adobe Developer App Builder is an Adobe-hosted gateway that combines several APIs, such as Adobe Commerce, a PIM, a CMS and your own services, into one GraphQL endpoint. A storefront or app sends one query and gets back exactly the fields it asked for, even if they come from three systems. It suits headless Adobe Commerce builds that would otherwise call several back ends from the browser. It is not a replacement for a CDN, an integration platform or a data sync.

What API Mesh does

Adobe describes API Mesh as an orchestration layer for joining private and third-party APIs with Adobe products. In practice it does four jobs:

• Unifies sources. Each back end becomes a "source" in a mesh configuration. The mesh builds a single GraphQL schema from all of them.
• Links data across sources. You can extend a Commerce product type with fields from another system, for example editorial content from a CMS keyed by SKU.
• Transforms schemas. Rename, prefix or filter types and fields so the combined schema stays clean.
• Adds a protected edge. Adobe lists a web application firewall and DDoS protection as part of the gateway.

It also solves a specific Adobe Commerce problem. Adobe's GraphQL documentation notes that on PaaS, the core schema and the schemas of services such as Catalog Service, Live Search and Product Recommendations do not natively interact. Combining them in one query requires API Mesh.

Supported sources

A mesh can pull from three kinds of source, each with its own handler:

• GraphQL: Adobe Commerce GraphQL, Adobe Commerce as a Cloud Service, or any other GraphQL API.
• OpenAPI: REST APIs described by an OpenAPI document, which covers most modern PIM, CMS and ERP APIs.
• JSON Schema: REST or JSON endpoints without an OpenAPI description, defined by JSON schemas.

Source names may contain only letters and numbers. If you change a source's schema, update the mesh so it picks up the change.

Architecture table: what to combine, caching and limits

This table maps the usual sources in a headless Adobe Commerce stack to what you would pull through the mesh and how to treat caching for each. Caching notes reflect Adobe's documented behavior: a response is considered for caching only when at least one source in the query returns a cache-control header (or you set a default in the mesh configuration), and when sources disagree the mesh picks the lowest, most restrictive value.

The PIM row assumes the PIM still feeds Commerce for searchable attributes. Our Magento PIM integration guide explains that split.

Caching rules worth knowing

Adobe's API Mesh caching documentation sets out these rules (checked November 2026):

• Caching is opt-in. It is disabled by default and switched on with "cache": true in the mesh's responseConfig.
• Only eligible requests are cached: GET or POST query operations, not mutations or introspection queries, and only responses with a 2xx status, no GraphQL errors and public cache-control directives.
• Sources drive caching. The mesh acts as a public cache that follows the cache-control headers your sources return. It never caches responses marked private or no-store, so customer-specific sources must send those directives. For sources that send no header, you can set a default cacheControl value in the configuration.
• Cache keys can vary by header. Sending an x-api-mesh-vary header with a list of header names adds those headers and their values to the cache key, which is how Adobe suggests segmenting by customer group.
• GET requests are limited to 2,048 characters. Keep cacheable GET queries short.
• Purging uses aio api-mesh:cache:purge -a, which deletes all cached responses for the mesh. Adobe recommends purging after configuration changes that could affect cached data.
• Your own CDN (Adobe's example is Fastly) is an alternative. Adobe recommends native caching, but if you bring a CDN, set "cache": false to avoid double caching, and note that POST requests are typically not supported in that setup.

A minimal mesh configuration

A mesh is defined in a JSON file and deployed with the Adobe I/O CLI. This simplified example joins Commerce GraphQL with a CMS that publishes an OpenAPI document. Hostnames are placeholders.

{ "meshConfig": { "sources": [ { "name": "Commerce", "handler": { "graphql": { "endpoint": "https://commerce.example.com/graphql" } } }, { "name": "Cms", "handler": { "openapi": { "source": "https://cms.example.com/openapi.json" } } } ], "responseConfig": { "cache": true } } }

Real projects add transforms, headers for store view and customer group, and resolvers that link a CMS type to a Commerce product. Adobe's documentation includes a recommended configuration for Adobe Commerce as a Cloud Service with those headers set.

Edge meshes and limits

Adobe moved API Mesh to edge infrastructure in 2024 and disabled legacy meshes on December 3, 2024. Meshes now run at the edge and are called through the edge-graph.adobe.io domain. One documented gap: replaceField transforms are not available on edge meshes, so older configurations that used them need rework.

To protect a mesh from expensive queries, Adobe documents an optional queryConfig block with limits such as maximum depth, tokens, aliases and query cost. All of these protections are off by default, so switch them on for public storefront meshes. Response size and timeout limits are not something you should design close to; keep slow back ends out of the hot path.

When API Mesh is the right tool

• A headless storefront needs Commerce data plus content or PIM data on the same page.
• You use Catalog Service or Live Search alongside core GraphQL and need them in one query.
• You want to hide several back-end APIs and their credentials behind one public endpoint.
• Mobile apps and web storefronts should share one API contract.

When it is not

• Data synchronization. Moving orders to an ERP or stock into Commerce is an event or batch job, not a query. See our ERP integration patterns.
• Admin or back-office integrations. These usually call Commerce REST directly. Our GraphQL vs REST guide explains why.
• A classic Luma or Hyvä storefront that renders server-side and does not call external APIs from the browser.
• Stores without App Builder access. API Mesh is part of App Builder, which Adobe licenses in packs. Adobe's App Builder FAQ says one or several packs come with Adobe Commerce on cloud infrastructure; what your contract covers depends on edition and licence, so confirm it with your Adobe account team. Our Adobe App Builder guide covers what that involves.

FAQ

Is API Mesh the same as GraphQL Mesh?

API Mesh is Adobe's hosted product. It builds on concepts from the open-source GraphQL Mesh project, but you configure and run it through Adobe's tools and infrastructure.

Does API Mesh slow down a storefront?

It adds a hop, but it can also remove several browser-to-API calls. The usual cause of slowness is a slow source. Cache public data and keep slow systems out of page-critical queries.

Can I use API Mesh with Magento Open Source?

A mesh can point at any GraphQL endpoint, but you need access to API Mesh itself, which comes through an Adobe Developer App Builder entitlement. Magento Open Source does not include one, so check with Adobe what a separate App Builder licence would involve before planning around it.

Planning a mesh

Start with the pages that need data from more than one system and list the fields each one needs. That list becomes your source and caching plan. Mistri designs and builds mesh layers as part of our headless Adobe Commerce development work.

Sources

Adobe Developer: API Mesh for Adobe Developer App Builder; Adobe Developer: API Mesh source handlers; Adobe Developer: API Mesh caching and cache-control headers; Adobe Developer: API Mesh update notice (edge meshes); Adobe Developer: App Builder FAQ (licensing); Adobe Developer: Adobe Commerce GraphQL overview. Checked November 2026.