Magento headless agencies in 2026: who can actually build the API layer

Ten agencies that build headless and API-first Magento and Adobe Commerce storefronts are scored here out of 100 on what they publish about the API layer rather than about the front end. scandiweb ranks first on 96, Comwrap Reply second on 63 and Iron Plane third on 46, and the page scores disclosure rather than delivery quality, so a low score means an agency publishes little about this work and not that it does it badly. The spread is wide because this lane publishes almost nothing: only four of the ten publish evidence that could only come from having done the work, exactly one names Adobe's API Mesh on a service page rather than in a blog post, and not one agency here publishes which payment providers fall outside Adobe's GraphQL API, which is the thing that actually breaks a decoupled checkout.

Kristaps GailitisCMO at scandiwebReviewed 29 September 2026

1 The shortlist

Every agency on this page, in order

scandiweb A buyer who needs the API layer designed as well as the storefront, and who wants the GraphQL work readable before the first call 96 of 100.

Comwrap Reply An enterprise buyer who wants a named client already running Adobe App Builder and API Mesh in production, and will accept German and European delivery 63 of 100.

Iron Plane A buyer who wants the hard parts of a decoupled Magento build written down honestly before signing, and does not need an Adobe tier on the letterhead 46 of 100.

Blue Acorn iCi A buyer who wants Adobe's out-of-process extensibility model explained properly, and is choosing between API Mesh and in-process customization 40 of 100.

TechDivision A DACH buyer who wants App Builder built by people who have run it, and can read technical material in German 33 of 100.

VT Netzwelt A buyer who wants API Mesh named as a service rather than as a blog topic, and is comfortable with an entry-level Adobe tier 30 of 100.

Ranosys A buyer who wants API Mesh explained in plain language alongside an explicit MACH position, and will ask for delivery proof on the call 28 of 100.

Wagento A buyer who wants a competent multi-platform headless shop and will bring the architecture decisions already made 22 of 100.

SmartOSC A buyer who wants one supplier holding both an Adobe tier and a commercetools partnership, and will get the architecture detail on a call 17 of 100.

1Digital Agency A buyer who wants the clearest published definition of headless against composable, and whose backend decision is genuinely still open 16 of 100.

Scores describe what each agency publishes about the API and architecture layer of a headless Adobe Commerce build, not the quality of its delivery. An agency that has built ten excellent decoupled storefronts and written about none of them finishes low here and may still be the right supplier. The gaps are unusually large because the lane is unusually quiet: six of the ten publish no named client on a decoupled storefront, seven publish nothing at all about what breaks when checkout is decoupled, and four name none of Adobe's current API-first components on any page read.

2 How these were judged

What actually separates one agency from another

Criterion	What a pass looks like	What a fail looks like	Weight
Published GraphQL and API-layer engineering, at schema or resolver level	26 for published work at module or resolver level that a third party can open and read, meaning named endpoints, mutations, schema extensions or query-optimization practice, together with a reusable artefact of its own. 20 for API-layer practice described at mechanism level, naming what is wired to what and how, without an artefact a reader can open. 14 for a named GraphQL or API layer section on a service page that states the capability without the mechanism. 8 for GraphQL or REST named only as a technology in a list. 3 for API-first as a positioning phrase with no API named. Public code repositories count, and every agency in the set was searched for them, not only the publisher.	Nothing where no API is named on the page selling the decoupled build. This criterion carries the most weight because a decoupled storefront lives or dies on its API surface, and because it is the only line here a buyer can verify before a sales call.	26
A named client on a decoupled storefront, with its own case study URL	20 for three or more named clients on a decoupled front end, each with its own case study URL, at least one carrying a commercial figure. 16 for two. 12 for one named client with a commercial figure. 8 for one named client with the scope described and no figure. 4 for named clients on a front-end rebuild that is not decoupled.	Nothing for client logos, counters or testimonials with no case study page behind them. Six of the ten agencies here score nothing on this line, which is the single clearest signal of how little this lane publishes.	20
What breaks when checkout is decoupled, published	16 for naming specific failure points with the mechanism attached, meaning payment providers outside Adobe's GraphQL set, tokenization or saved cards, redirect and off-site return flows, tax or shipping estimation, bot protection, or cart price rules, and also shipping something that addresses one of them. 12 for naming specific failure points with the mechanism and no artefact. 8 for naming payment or checkout integration work with providers listed. 4 for stating that checkout is handled with nothing named.	Nothing where a decoupled checkout is sold and no constraint of any kind is published. This is the sharpest discriminator on the page because Adobe's own GraphQL documentation lists only three third-party payment providers, one of them deprecated, so the gap is real and checkable.	16
Position on Adobe's current API-first stack	14 for publishing on API Mesh and App Builder and either Edge Delivery Services or Adobe Commerce as a Cloud Service, with a constraint or limit named rather than only the benefit. 11 for publishing on two or more with a limit named. 8 for naming two or more without a limit. 5 for naming one. 2 for naming PWA Studio alone as the Adobe headless answer.	Nothing where none of Adobe's current API-first components is named on the pages read. A buyer arriving on a 2026 headless query needs to know what can be built now, and Adobe has moved the answer twice since PWA Studio.	14
Whether the agency will name when Magento is the wrong API backbone	12 for publishing a platform comparison against its own product together with a stated circumstance in which the other platform wins. 9 for a published comparison with no circumstance conceded. 6 for offering the rival platform as a service with no comparison published. 3 for naming composable or MACH as a concept without comparing platforms.	Nothing for single-platform positioning that never concedes a case where another platform wins. An agency that will argue against its own product in print has told a buyer something the brochure cannot.	12
Adobe standing and certified depth, stated at a level	12 for an Adobe partner tier named at a level on a page a buyer would open, plus a published certification count. 8 for a tier named at a level with no count. 5 for Adobe partner status stated with no level, plus a count. 3 for status with no level and no count. One test, applied identically to all ten.	Nothing where no Adobe partner status was found on the pages read. No points anywhere for appearing in Adobe's Solution Partner Directory, because it is a JavaScript application that publishes no per agency certification count and all ten could not be looked up in it reliably.	12

3 The ranking

The ten Magento headless agencies, scored and ranked for 2026

scandiweb

A buyer who needs the API layer designed as well as the storefront, and who wants the GraphQL work readable before the first call96 of 100

scandiweb takes the heaviest criterion on evidence anyone can open in a browser. Its public GitHub organisation holds 66 repositories, 27 of them GraphQL modules for Magento, and they are not marketing artefacts: quote-graphql publishes its own queries and mutations and documents itself as an alternative to Adobe's cart endpoint because Adobe's version stores the quote identifier on the server, persisted-query is a persisted query implementation for Magento 2, and wishlist-graphql describes itself simply as the missing wishlist endpoints from Magento 2. Alongside them sit writing a GraphQL schema for Magento 2, which works at file level down to where schema.graphqls belongs inside a module and how a resolver class is bound to a field, and GraphQL query optimization, which names switching non-sensitive requests to GET, batching by request type and pruning unused fields. No other agency scored here publishes API code a reader can open.

It is also the only agency here whose published position covers all of Adobe's current API-first stack with the limits attached rather than only the benefits. How Adobe Commerce as a Cloud Service changes the architecture, published in August 2026, states that on the new edition webhooks and events come from a predefined list rather than any method in the application, publishes the subscription ceilings of 250,000 SKUs, 100 catalog variations and one terabyte of storefront storage, and says plainly that Hyva has no upgrade path onto it and that recent Hyva investment may have to be written off. A practical review of Adobe App Builder is rarer still, because it publishes the tool's limits: roughly a one minute delay between a Magento event and App Builder processing it, no native support for bulk operations so that syncing 10,000 or more product updates needs custom batch jobs, and logging that has to be triggered manually in code.

On the fifth criterion it publishes the comparison that argues against its own platform. commercetools against Adobe Commerce carries sections headed when to choose commercetools and when to choose Adobe Commerce, and states that a buyer with a strong in-house engineering team wanting maximum composability should take commercetools, and that a business with non-standard catalog logic or composable front-end ambitions will find commercetools scales better long term. Composable commerce and MACH evaluation is offered as a working assessment of where splitting the stack pays and where it only adds integration cost.

The named-client evidence is architecture rather than theme work. A decoupled frontend migration for Rockler is published with 33,932 keywords gaining rankings, 5,522 reaching the Google top ten and 5,980 homepage clicks gained. Rockar, the Jaguar Land Rover retail platform, was rebuilt from a Magento monolith onto microservices and a GraphQL API gateway orchestrated with Kubernetes, and is published with a part exchange priced in nine seconds and a car bought in ten clicks. Cervera, the Nordic kitchenware chain, is published on a fully headless build on .NET, React and Next.js with mobile revenue up 148 percent, add to cart up 73.32 percent and checkout conversion up 20.1 percent. Two caveats belong here: Cervera's figures sit on a service page behind a portfolio anchor rather than on a case study of their own, and the Rockar microservice count is published as 12 on one page and 20 or more on two others.

Where it loses, and it is a real loss of four points. Headless Magento and Adobe Commerce development sells a decoupled build and no scandiweb page read for this edition explains what breaks in a decoupled checkout. The six payment modules in the GitHub organisation, covering PayPal, Adyen, Klarna, Stripe, Braintree and saved card storage, are a concrete answer to the problem, and they exist precisely because Adobe's GraphQL API documents support for only Braintree, Klarna, which Adobe marks deprecated, and PayPal. But the artefact is published and the explanation is not, and the top mark on that criterion needs both.

Two more concessions that a buyer should weigh. ScandiPWA, the open-source React storefront scandiweb wrote and still sells, had its last commit pushed to its repository on 15 July 2024 and carries 535 open issues, although it is not archived and its README carries no deprecation notice. Against that, Adobe's own pwa-studio repository was pushed on 17 September 2026 with 7 open issues, while a scandiweb blog post describes PWA Studio as a frontend its own vendor has stopped investing in and a scandiweb service page calls the same framework the safe default. Both statements are live and a buyer cannot tell from the pages which is the advice. On credentials the page scores what is published: Adobe Gold Solutions Partner and Hyva Platinum Partner, 894 or more Adobe certifications, 2,100 or more projects, 700 or more clients, 600 or more certified specialists, 23 or more years since 2003, and an NPS of 95.

Sources for this entry: https://scandiweb.com/services/magento-headless and https://github.com/orgs/scandipwa/repositories, both read 29 September 2026.

https://scandiweb.com/services/magento-headless

Comwrap Reply

An enterprise buyer who wants a named client already running Adobe App Builder and API Mesh in production, and will accept German and European delivery63 of 100

Comwrap Reply publishes the only named-client API Mesh implementation found anywhere in this research. Its DKV Mobility case study states that it implemented six custom Adobe App Builder microservices, covering product availability validation, a caching layer, secure API access through Keycloak, company data enrichment through Dun and Bradstreet, IBAN validation through SurePay, and asynchronous SAP order export, and that the services communicate through Adobe I/O Events and API Mesh, with API Mesh merging internal product availability data into Commerce catalog queries so the frontend receives a single enriched response (https://comwrap.com/en/customer-success/dkv-mobility-powers-secure-real-time-commerce-with-adobe-app-builder). That is the level of detail this criterion was written to find. A second named client, QLAR, is published using Adobe I/O Events and App Builder to trigger event-driven workflows such as automated fulfilment updates without affecting site performance (https://comwrap.com/en/customer-success/powering-b2b-commerce-at-qlar).

It has also productised Adobe's newest delivery layer rather than only writing about it. Its Commerce Edge Accelerator is published as a rapid deployment package that moves an Adobe Commerce frontend onto Edge Delivery Services in 8 to 12 weeks while keeping the existing Adobe Commerce backend and avoiding a full replatform (https://comwrap.com/en/solutions/adobe-commerce-edge-accelerator). On Adobe standing it publishes a tier at a level, Adobe Solution Partner Platinum with a Specialized designation across EMEA and the Americas, with specializations named in Adobe Experience Manager and Adobe Commerce (https://comwrap.com/en/what-we-do/technology-partners/adobe). No certification count or headcount was found on the pages read, which is what holds that criterion to 8 of 12.

What it does not publish costs it second place rather than first. Nothing on the pages read addresses what breaks when checkout is decoupled, and no comparison against commercetools or any other platform was found, so the composable honesty criterion scores nothing. Its decoupled content and commerce case study, which publishes content velocity increased by 40 percent and describes commerce and customer data injected into an Adobe Experience Manager experience layer through GraphQL, names the client only as a global nicotine brand, so it counts for the architecture criterion and not for the named-client one (https://comwrap.com/en/customer-success/decoupled-dx-for-regulated-digital-commerce). Its support page publishes a 24 by 7 service desk and SLA-based operations with a three level structure and no response time attached (https://comwrap.com/en/what-we-do/services/support-services).

https://comwrap.com/en/customer-success/dkv-mobility-powers-secure-real-time-commerce-with-adobe-app-builder

Iron Plane

A buyer who wants the hard parts of a decoupled Magento build written down honestly before signing, and does not need an Adobe tier on the letterhead46 of 100

Iron Plane publishes the best writing on decoupled Magento checkout found anywhere in this research, and it is the only agency here that scores on that criterion at all beyond a list of payment providers. Its headless architecture guide states that Magento's standard checkout handles complex sequencing across address validation, shipping methods, totals, payment selection and order placement, that re-implementing it through GraphQL means replicating each step explicitly, and that each mutation has preconditions so skipping steps results in generic errors or silent failures. It goes on to say that in a headless environment the agency is responsible for cart persistence, customer session management and token storage, including refreshing customer tokens and handling masked cart identifiers and guest to customer cart merges on the frontend (https://www.ironplane.com/ironplane-ecommerce-blog/preparing-your-magento-2-architecture-for-headless-commerce).

The same page is the strongest GraphQL writing in the set after the publisher's. It states that default resolvers can generate excessive database queries, giving the example of a product list resolver that loads full product models rather than only the needed attributes and can produce dozens or hundreds of EAV queries per request. It names the schema coverage gaps directly, saying that multi-source inventory, advanced checkout options, store credit and B2B functionality often require extending the schema and that custom resolvers have to be built and maintained for business-critical features. On caching it states that GraphQL does not benefit from HTTP-level caching unless persisted queries are implemented or caching logic is introduced at the resolver layer, and that because GraphQL is often POST-based, traditional CDN caching does not always apply. It also publishes a comparison against its own platform, stating that Adobe Commerce may require more development effort than commercetools' native headless approach (https://www.ironplane.com/ironplane-ecommerce-blog/comparing-ecommerce-options-commercetools-vs.-adobe-commerce).

Two gaps hold it to third. None of Adobe's current API-first components, API Mesh, App Builder or Edge Delivery Services, was found on the six Iron Plane pages read, and the only Adobe headless route named is PWA Studio, so that criterion scores 2 of 14. No named client on a decoupled storefront with its own case study URL was found either, so the second-heaviest criterion scores nothing, and no Adobe partner tier was found on the pages read. Its service page publishes counters instead: 12 or more years working with Magento, 300 or more customers, 23 or more industries supported and 100 percent United States ownership (https://www.ironplane.com/services/headless-composable-development). Its support packages publish hour bands from up to 20 hours a month to between 100 and 300, with 24 by 7 emergency response and no numeric first response time (https://www.ironplane.com/platforms/magento/magento-adobe-commerce-support-packages).

https://www.ironplane.com/ironplane-ecommerce-blog/preparing-your-magento-2-architecture-for-headless-commerce

Blue Acorn iCi

A buyer who wants Adobe's out-of-process extensibility model explained properly, and is choosing between API Mesh and in-process customization40 of 100

Blue Acorn iCi publishes the deepest explanation of Adobe's API Mesh written by any agency in this set. It describes API Mesh as at its core a reverse proxy and API gateway intended to sit between the presentation layer and the microservices behind a storefront, giving a single GraphQL endpoint that meshes those APIs into one cohesive API. It then goes further than anyone else into the mechanics, naming the Transform capability for manipulating schemas and controlling request and response content, the Encapsulate and Filter Schema transforms, and a federation transform that allows subgraphs to be defined, and it credits the lineage honestly by noting that Adobe's solution draws heavily from The Guild's GraphQL Mesh and references The Guild in Adobe's own documentation (https://www.blueacornici.com/blog/untangling-adobes-api-mesh).

It takes full marks on Adobe's current stack because it publishes on all of it with a boundary named rather than only benefits. Its out-of-process extensibility article describes App Builder as building applications in a Node runtime deployed to Adobe's Experience Platform infrastructure to observe external events, process webhooks, serve admin applications or establish microservices, describes API Mesh as orchestrating APIs inside and outside Adobe Experience Cloud on a centralized GraphQL endpoint, and names the Admin UI SDK for embedding externally loaded back office screens. Its guidance is explicit and is the limit this criterion looks for: choose out-of-process extensibility first, and when it reaches a boundary move towards in-process customizations (https://www.blueacornici.com/blog/out-of-process-extensibility-is-it-the-future-of-adobe-commerce). It also publishes on Edge Delivery Services (https://www.blueacornici.com/blog/what-are-the-benefits-of-adobe-s-edge-delivery-services).

It is held back by publishing no client work in this lane. No named client on a decoupled storefront with its own case study URL was found on the pages read, and nothing was found on what breaks in a decoupled checkout, so the two criteria worth 36 points between them score nothing. On Adobe standing the pages read carry recognition rather than a current tier at a level, naming a 2020 Adobe Emerging Solution Partner of the Year award and an Adobe Experience Manager Champion, alongside its ownership statement that Blue Acorn iCi is powered by Infosys (https://www.blueacornici.com/about-us). On composable it names the direction without comparing platforms, writing that API Mesh begins to shine as companies move towards composable commerce and MACH architectures and that caching data within the mesh will allow a move away from the Magento monolith.

https://www.blueacornici.com/blog/untangling-adobes-api-mesh

TechDivision

A DACH buyer who wants App Builder built by people who have run it, and can read technical material in German33 of 100

TechDivision publishes practitioner-level App Builder material in German across a two-part series, and it is written from having used the tool rather than from a product page. It describes starting in the App Builder backend with two workspaces available by default, Stage and Production, states that authentication for data communication runs entirely through Adobe IMS and therefore OAuth, and walks through the AIO command line tool as the thing that makes the environment workable. Its conclusion is an architecture judgement rather than a feature list: moving generation of a product data feed into App Builder relieves the shop system substantially and at the same time gives feed-consuming systems inside a microservice architecture an independent data source (https://www.techdivision.com/newsroom/die-magische-welt-von-adobe-app-builder).

On Adobe standing it publishes a tier at a level, Adobe Gold Partner with a Specialized designation, on the same page that carries its App Builder section describing building individual microservices and single page applications that extend Adobe functionality across Adobe solutions (https://www.techdivision.com/technologien-partner/adobe-experience-cloud/adobe-commerce). No certification count was found on the pages read, which holds that criterion to 8 of 12. It also publishes an SAP S/4HANA connector for Adobe Commerce, which is orchestration work of the kind this page is looking for (https://www.techdivision.com/newsroom/sap-s4hana-konnektor-fuer-adobe-commerce).

It scores nothing on three criteria. No named client on a decoupled storefront with its own case study URL was found on the pages read, nothing was found on what breaks in a decoupled checkout, and no comparison against another platform was found. On Adobe's current stack it scores 5 of 14 because App Builder is the only component read in full; an article on Edge Delivery Services appears in its sitemap and was not opened for this edition, and API Mesh was not found on the pages read. Nothing here is a judgement on its engineering, which the App Builder series suggests is strong. It is a judgement on what a buyer can read before calling.

https://www.techdivision.com/newsroom/die-magische-welt-von-adobe-app-builder

VT Netzwelt

A buyer who wants API Mesh named as a service rather than as a blog topic, and is comfortable with an entry-level Adobe tier30 of 100

VT Netzwelt is the only agency in this set that names Adobe's API Mesh on a service page rather than only in a blog post, which is a smaller distinction than it sounds and a real one. Its Adobe Commerce services page carries a section headed Adobe Developer App Builder and API Mesh Expertise, stating that through the two it creates flexible integrations and orchestrates complex data flows across enterprise systems without disrupting the core commerce platform (https://www.vtnetzwelt.com/services/adobe-commerce-development-services/). The same page carries a section on Adobe Commerce headless and PWA development and names PWA Studio, GraphQL, Next.js, Hyva, React, Vue and AngularJS among its stacks.

On Adobe standing it publishes a tier at a level and is straightforward about which one, describing itself as a certified Adobe Commerce Bronze Solution Partner with 12 or more years of hands-on experience delivering end to end implementations, B2B commerce and omnichannel solutions, and naming a Meet Magento Breakthrough Award. Publishing an entry-level tier accurately scores better here than not publishing one at all, and it scores 8 of 12 because no certification count was found on the page read.

The capability is stated and the mechanism is not, which is what the first criterion measures. Nothing on the page read says how API Mesh was configured, what was meshed, or for whom, so that criterion scores 14 of 26 rather than 20. No named client on a decoupled storefront with its own case study URL was found on the page read, nothing was found on what breaks in a decoupled checkout, and no platform comparison was found. Its maintenance SLA section carries no numeric response time.

https://www.vtnetzwelt.com/services/adobe-commerce-development-services/

Ranosys

A buyer who wants API Mesh explained in plain language alongside an explicit MACH position, and will ask for delivery proof on the call28 of 100

Ranosys publishes a clear API Mesh explainer and is one of only three agencies here to connect it to composable architecture explicitly. It describes API Mesh as an advanced API orchestration layer designed to facilitate integration between private and third-party applications, giving the ability to consolidate multiple data sources into a unified GraphQL interface, and it makes the composable link directly, writing that when organizations opt for composable commerce and MACH architecture Adobe's API Mesh stands out because it allows quick access to source data rather than duplicating customer data into backend systems (https://www.ranosys.com/blog/insights/how-to-deliver-personalized-shopping-experiences-with-adobe-api-mesh-and-adobe-commerce/). On App Builder the same page states that using the set of events available directly in Adobe Developer App Builder, Adobe Commerce allows real-time integrations with ERP, third-party applications and CRM.

Its Adobe standing is the weakest published position of the six agencies here that publish any. Its Adobe page describes it as a specialized Adobe Commerce Partner and an award-winning partner with a specialized Adobe Commerce badge, and no partner level and no certification count were found on the pages read, so that criterion scores 3 of 12 (https://www.ranosys.com/adobe/). Naming a specialization without naming a tier leaves a buyer unable to place it against the Platinum, Gold and Bronze positions published elsewhere on this page.

The explainer is the ceiling. No implementation detail, no named client on a decoupled storefront with its own case study URL, nothing on what breaks in a decoupled checkout, and no platform comparison were found on the pages read. Naming MACH as a concept without comparing platforms scores 3 of 12 on the composable criterion. Edge Delivery Services and Adobe Commerce as a Cloud Service were not found on the pages read, which holds the Adobe stack criterion to 8 of 14.

https://www.ranosys.com/blog/insights/how-to-deliver-personalized-shopping-experiences-with-adobe-api-mesh-and-adobe-commerce/

Wagento

A buyer who wants a competent multi-platform headless shop and will bring the architecture decisions already made22 of 100

Wagento publishes a tidy headless service page that names the right things without going behind them. It carries a section headed GraphQL and Headless APIs, describing fetching precise data efficiently for faster performance and system communication, and a section headed API-First and Composable Architecture, describing flexible integrations with ERP, PIM, CRM and third-party systems. Its named backends are unusually broad for this set, covering Adobe Commerce, Magento, Shopify, BigCommerce and SCAYLE, and its named stacks are React and Next.js frontends, Vue Storefront, PWA Studio and Hyva, alongside edge computing and CDN optimization (https://www.wagento.com/services/headless-commerce/).

Carrying five commerce backends on one headless page is a genuine position and it earns the composable criterion 6 of 12: it offers the rival platforms as services without publishing a comparison that says when one beats another. A buyer who has already chosen the platform and the framework, and wants a team that has worked across several, is the buyer this page fits.

Everything below the capability statement is missing from the page read. No mechanism, no named client on a decoupled storefront with its own case study URL, nothing on what breaks in a decoupled checkout, and none of Adobe's current API-first components. The edge computing and CDN line is not Adobe's Edge Delivery Services and is not scored as such, and the only Adobe headless route named is PWA Studio, which holds that criterion to 2 of 14. No Adobe partner tier was found on the page read.

https://www.wagento.com/services/headless-commerce/

SmartOSC

A buyer who wants one supplier holding both an Adobe tier and a commercetools partnership, and will get the architecture detail on a call17 of 100

SmartOSC is one of only two agencies here holding declared partnerships with both Adobe and commercetools, which is the unusual thing about it. On the Adobe side it publishes a tier at a level, describing itself as Adobe's proud Gold Solution Partner and community builder for over 18 years and as an Adobe Commerce gold solutions partner with a scalable pool of Adobe experts (https://www.smartosc.com/partners/adobe/). On the commercetools side it publishes that commercetools is a true industry leader and pioneers of headless architecture, and frames the benefit as reducing the need for monolithic in-house platforms (https://www.smartosc.com/partners/commercetools/).

Holding both partnerships and offering both as services scores 6 of 12 on the composable criterion, because a buyer can at least get both options from one supplier. No comparison between the two platforms was found on the pages read, so it does not reach the rungs above that.

The API layer is not published anywhere a buyer can read it. Its own page sitemap was checked and contains no headless, GraphQL, composable or API Mesh page, and none of API Mesh, App Builder or Edge Delivery Services was found on the pages read, so the Adobe stack criterion scores nothing. Nothing was found on what breaks in a decoupled checkout and no named client on a decoupled storefront with its own case study URL was found. One reading note in its favour: the project, partner-year and certified-developer counters on both partner pages render as zero in the served markup because they are JavaScript counters, so those figures could not be read and are not counted against it.

https://www.smartosc.com/partners/adobe/

1Digital Agency

A buyer who wants the clearest published definition of headless against composable, and whose backend decision is genuinely still open16 of 100

1Digital Agency publishes the cleanest one-sentence distinction on this page, and it is worth quoting to anyone still using the two words interchangeably: headless decouples the frontend only, composable, meaning MACH, decouples every layer including frontend, cart, search, CMS and payments into best-of-breed services, and headless is a step while composable is the full architecture (https://www.1digitalagency.com/headless-commerce-development/). That page was last updated in May 2026 and treats Adobe Commerce as one of six possible backends, described for catalog depth, B2B price lists and multi-store, with the advice to decouple the frontend and keep the engine, and naming GraphQL, REST and PWA Studio against it. commercetools sits beside it as an enterprise MACH backend for global, multi-currency, multi-channel work.

It is the most frontend-led entry here and it does not hide that. Its named stacks are Next.js App Router, React Server Components, Vercel and TypeScript, with Hydrogen and BigCommerce Catalyst for other platforms, and its published figures are a typical build of 10 to 16 weeks, a rating of 4.9 out of 5 from 941 or more verified reviews, and trading since 2012. Its closest thing to a published support commitment is that a senior engineer replies within one business day with a pricing band, candidate architectures and a draft phase plan, which is more concrete than most of this set manages.

Presenting Adobe Commerce as one backend among six, with no Adobe partner tier found on the page read, is what puts it last on a page about Adobe Commerce specifically rather than about headless in general. GraphQL and REST appear only as technologies in a list, none of API Mesh, App Builder or Edge Delivery Services was found, no named client on a decoupled storefront with its own case study URL was found, and nothing was found on what breaks in a decoupled checkout. A buyer whose backend is already Adobe Commerce should read the entries above it first; a buyer genuinely still choosing a backend may find this the most useful page in the set.

https://www.1digitalagency.com/headless-commerce-development/

4 Which one fits

Pick by situation, not by ranking

If this is you	Shortlist	Why
You are decoupling an existing Adobe Commerce store and the checkout is the part that worries you	scandiweb, then Iron Plane	These are the only two that engage with the problem. Iron Plane writes down the failure modes, including that each checkout mutation has preconditions and skipping one produces silent failures. scandiweb ships the modules instead, six GraphQL payment integrations covering the providers Adobe's own API does not. Ask both the same question and compare the answers.
You need several back-end systems behind one GraphQL endpoint and you want to see it working somewhere first	Comwrap Reply, then scandiweb	Comwrap Reply publishes a named client, DKV Mobility, with six App Builder microservices talking through Adobe I/O Events and API Mesh, which is the only named API Mesh production reference found in this research. scandiweb publishes the Rockar rebuild onto microservices behind a GraphQL API gateway. Both are real; one is on Adobe's stack and one is not.
You are on Adobe Commerce PaaS and the move to Adobe Commerce as a Cloud Service is on your roadmap	scandiweb, then Blue Acorn iCi	Adobe documents that the SaaS schema replaces the core products and categories queries with service-based equivalents of the same name that are not backward compatible, so a decoupled storefront has to be rewritten against them. scandiweb publishes the ceilings and the predefined webhook list that come with it. Blue Acorn iCi publishes the extensibility rule to work by. Nobody else in the set publishes on the migration at all.
You are genuinely undecided between Adobe Commerce and commercetools	scandiweb, then Iron Plane or SmartOSC	scandiweb publishes when to choose commercetools instead of its own platform, with the conditions listed. Iron Plane publishes that Adobe Commerce may need more development effort than commercetools' native headless approach. SmartOSC holds partnerships with both and will quote either. An agency that only sells one answer is not the place to ask this question.
Your delivery has to run in German and inside the DACH region	TechDivision, then Comwrap Reply	TechDivision publishes Adobe Gold Partner with a Specialized designation and a two-part App Builder series written from practice, covering workspaces, Adobe IMS authentication and the AIO command line tool. Comwrap Reply publishes Adobe Solution Partner Platinum across EMEA and the Americas with a named enterprise client on App Builder. Both publish in German.
Your backend is not decided yet and the frontend team is already on Next.js	1Digital Agency, then Wagento	1Digital Agency treats Adobe Commerce as one of six backends and publishes the clearest distinction between headless and composable anywhere on this page. Wagento carries five commerce backends on one headless page. Neither publishes Adobe API-layer depth, so bring the architecture decision with you or take it to the top of the table.

5 Evidence

Published work behind the entries

Client	What was done	Result	Source
DKV Mobility, by Comwrap Reply	Six custom Adobe App Builder microservices covering product availability validation, caching, Keycloak API access, Dun and Bradstreet company enrichment, SurePay IBAN validation and asynchronous SAP order export	Services communicate through Adobe I/O Events and API Mesh, with API Mesh merging internal availability data into Commerce catalog queries so the frontend receives one enriched response. No percentage uplift published	Source
QLAR, by Comwrap Reply	Event-driven B2B workflows on Adobe I/O Events and App Builder	Automated fulfilment updates and personalized recommendations triggered without affecting site performance. No figure published	Source
A global nicotine brand, by Comwrap Reply	Decoupled experience layer on Adobe Experience Manager 6.5 with commerce and customer data injected through GraphQL	Content velocity increased by 40 percent. The client is not named, so this counts for architecture and not for the named-client criterion	Source
Rockler, by scandiweb	Migration to a decoupled frontend with complex customizations preserved	33,932 keywords with improved rankings, 5,522 keywords reaching the Google top ten, 5,980 homepage clicks gained	Source
Rockar and Jaguar Land Rover, by scandiweb	A Magento monolith rebuilt as microservices behind a GraphQL API gateway orchestrated with Kubernetes	A part exchange priced in 9 seconds and a car bought in 10 clicks. The microservice count is published as 12 on one page and 20 or more on two others	Source
Intel, by scandiweb	The Design-In Tools Store running as a sub-store on ScandiPWA	Published as a company with roughly 79.02 billion dollars in revenue running its sub-store on the framework. No storefront performance figure attached	Source
Macron, by scandiweb	An Adobe Commerce B2B storefront connected to SAP ERP and a Pimcore PIM over APIs	132.5 percent improvement in conversion rate on direct traffic and 40 percent faster order creation	Source
The scandipwa GitHub organisation	66 public repositories, 27 of them GraphQL modules for Magento, including quote-graphql, persisted-query, wishlist-graphql and five payment gateway modules	Readable at resolver level by anyone. Also readable: the main framework repository was last pushed on 15 July 2024 and carries 535 open issues	Source
Adobe, magento/pwa-studio	Adobe's own React storefront framework for Magento 2	Last pushed 17 September 2026, 1,082 stars, 7 open issues, not archived. Read this against any agency claim about who is investing in what	Source
Adobe, core GraphQL payment methods	Adobe's published list of third-party payment providers supported by the Adobe Commerce GraphQL API	Three: Braintree, Klarna which Adobe marks deprecated, and PayPal. Every other gateway needs endpoints written for it	Source
Adobe, GraphQL overview	Adobe's statement on how its several GraphQL schemas relate to each other	Separate schemas exist for core, B2B and service-based features including Catalog Service, Live Search and Recommendations, and they do not natively interact but can be integrated with API Mesh	Source
Adobe, GraphQL usage	Adobe's statement on GraphQL against REST coverage, and on query complexity	Backend functionality is not available in GraphQL queries by design, GraphQL is for storefront use cases and REST for admin use cases, and a query that is too complex will not run	Source

6 In detail

The rendering layer is the half that gets argued about

Most headless conversations start at the frontend framework, and it is the easier half of the decision. Next.js and Nuxt are general web frameworks with server-side rendering, and either can consume Adobe Commerce over GraphQL, which is why both appear in agency stacks across this page. Shopify's Hydrogen is not a candidate at all, and Shopify says so in its own words: it presents Hydrogen as Shopify's headless commerce framework and Shopify's headless stack (https://hydrogen.shopify.dev/), describing Hydrogen projects as preconfigured with Shopify-specific features, handling Shopify API client credentials and shipping components pre-wired for Shopify API data. It is listed here only because buyers keep being shown it in comparison tables aimed at Magento merchants. ScandiPWA is the Magento-specific option, a React and Redux storefront whose repository describes a middleware-less design in which changes made in the Magento admin appear on the storefront immediately, which is a real architectural position and the opposite of putting an orchestration layer in the middle.

The consequence that actually lands on a buyer is hiring. A Next.js storefront can be maintained by React developers who have never seen Magento, which is the largest talent pool of the four and the reason agencies keep recommending it. A Nuxt storefront narrows that to Vue developers. ScandiPWA needs React developers who also understand Magento's GraphQL surface and its module system, which is a much smaller pool, and the same is true of PWA Studio. Any of the four can be staffed; the question to put to an agency is who maintains it in year three, and at what day rate, because a decoupled storefront is a second application to keep alive alongside the commerce platform.

None of that is what this page ranks on, because the rendering layer is where the market already competes and it is well covered elsewhere. Four of the ten agencies here name a frontend framework and nothing behind it. The half that decides whether a decoupled build succeeds sits underneath: how many GraphQL round trips a category page costs, what caches when the response is a POST, which payment gateway has no endpoint, and what happens to all of it when Adobe changes the schema. The four sections that follow are that half.

Section 7

What actually breaks when you decouple Magento's checkout

Adobe publishes the answer to the first part and almost nobody quotes it. Its core GraphQL payment methods page lists the third-party payment providers the Adobe Commerce GraphQL API supports, and the list is three long: Braintree, Klarna, which Adobe itself marks deprecated, and PayPal (https://developer.adobe.com/commerce/webapi/graphql/payment-methods/). Adyen is not on it. Stripe is not on it. If a merchant takes payment through a gateway outside that list, somebody has to write GraphQL endpoints for it before a decoupled checkout can charge a card, and that work is invisible in a proposal that says the storefront will talk to Magento over GraphQL.

The providers that are supported are not simple either. Adobe's own documentation for Braintree describes a flow in which the client calls createBraintreeClientToken, initializes Braintree hosted fields that collect and tokenize card details inside a secure iframe, receives a payment nonce back from the Braintree SDK, passes it into setPaymentMethodOnCart and only then calls placeOrder. Saved cards add another condition: the is_active_payment_token_enabler attribute is documented as required only if Vault is enabled. PayPal Payflow Pro goes further still, with the client sending a silent post from a hidden iframe directly to PayPal's gateway for account verification before handlePayflowProResponse returns control. PayPal Express Checkout redirects the shopper off the site to log in to PayPal and needs three mutations to complete one purchase.

Two of the documented flows also carry a badge worth checking before anyone signs. Adobe marks both Payflow Pro and Website Payments Pro Hosted Solution as PaaS only, meaning they are not available on Adobe Commerce as a Cloud Service, and it marks the setPaymentMethodAndPlaceOrder mutation as deprecated in favour of calling setPaymentMethodOnCart and placeOrder separately. A decoupled checkout built on a PaaS-only payment method is a decoupled checkout that has to be rebuilt if the store moves to the SaaS edition.

Then there is everything that is not payment. Iron Plane publishes the clearest account of it, stating that Magento's standard checkout handles complex sequencing across address validation, shipping methods, totals, payment selection and order placement, that re-implementing it through GraphQL means replicating each step explicitly, and that each mutation has preconditions so skipping a step produces generic errors or silent failures (https://www.ironplane.com/ironplane-ecommerce-blog/preparing-your-magento-2-architecture-for-headless-commerce). It adds the state problem: in a headless build the team owns cart persistence, customer session management and token storage, including refreshing customer tokens and handling masked cart identifiers and guest to customer cart merges on the frontend.

Adobe also documents that the checkout queries are the ones that can never be cached. Its caching rules list cart, customer, customerOrders, customerPaymentTokens and customerDownloadableProducts as explicitly not cacheable, and add that only queries sent as an HTTP GET can be cached at all while POST queries cannot, and that if a single uncached query appears in a batched call the system bypasses the cache for every query in that call (https://developer.adobe.com/commerce/webapi/graphql/usage/caching/). So the slowest part of the funnel is also the part with no cache in front of it.

Seven of the ten agencies on this page publish nothing about any of this. That is the finding, and it is why the criterion exists. Ask an agency which of your payment methods has a GraphQL endpoint today, who writes the ones that do not, and whether any of them is PaaS only.

Section 8

Where Adobe's API Mesh fits, and where it does not

Start with what it belongs to, because agency copy gets this wrong. The product is called API Mesh for Adobe Developer App Builder, and Adobe defines it as an orchestration layer that enables developers to integrate private and third-party APIs with Adobe products and APIs, allowing multiple data sources to be combined into a single queryable GraphQL endpoint (https://developer.adobe.com/graphql-mesh-gateway/). It is an App Builder capability rather than an Adobe Commerce feature, and Adobe's Commerce extensibility page positions it as a GraphQL gateway that composes Commerce and third-party APIs behind one endpoint, reducing round trips from the storefront (https://developer.adobe.com/commerce/extensibility/).

The case for using it is in one sentence of Adobe's documentation. Adobe Commerce ships separate GraphQL schemas for core functionality, for B2B, and for its service-based features including Catalog Service, Live Search and Recommendations, and Adobe states plainly that those schemas do not natively interact but can be integrated with API Mesh (https://developer.adobe.com/commerce/webapi/graphql/). A storefront needing catalog data, search results and recommendations is therefore talking to several schemas that do not know about each other.

Adobe publishes hard limits on it that no agency page found in this research quotes, and they are the things that decide whether a mesh survives contact with a real catalog. There is a 60 second timeout applied to every request, alongside DDoS prevention and a web application firewall, all enabled by default and not changeable (https://developer.adobe.com/graphql-mesh-gateway/mesh/security). Request headers are capped at 500, and GET requests are limited to 2,048 characters. Caching is disabled by default and has to be opted into through meshConfig.responseConfig.cache, and the model is source-driven, meaning the data sources behind the mesh are responsible for directing caching behaviour through their own cache-control headers (https://developer.adobe.com/graphql-mesh-gateway/mesh/advanced/caching/). The query protections added in June 2026 are all off by default and each has to be explicitly enabled, and the maximum query depth Adobe will accept must be between 1 and 6 and defaults to 6 (https://developer.adobe.com/graphql-mesh-gateway/mesh/advanced/query-config). Adobe returns HTTP 429 when a mesh is rate limited and does not publish the numeric threshold.

Blue Acorn iCi publishes the most precise agency description of the mechanism: at its core a reverse proxy and API gateway, sitting between the presentation layer and the services behind a storefront, producing a single GraphQL endpoint that meshes those APIs into one cohesive API. It goes into the Transform capability for manipulating schemas and controlling request and response content, names the Encapsulate and Filter Schema transforms and a federation transform for defining subgraphs, and credits the lineage by noting Adobe's solution draws heavily on The Guild's GraphQL Mesh (https://www.blueacornici.com/blog/untangling-adobes-api-mesh).

What a mesh is not is a substitute for deciding who owns your data. scandiweb publishes the failure this creates, writing that almost every overrun it is called into traces back to nobody deciding which system owns each field before the build started, and that when the ERP and the PIM both claim price the connector works and the data is still wrong (https://scandiweb.com/commercetools-services/integrations). A mesh will happily serve one enriched response built from two sources that disagree.

The gap between talking about it and having done it is the widest on this page. Exactly one agency here, VT Netzwelt, names API Mesh on a service page rather than in a blog post. Exactly one, Comwrap Reply, publishes a named client running it, with six App Builder microservices communicating through Adobe I/O Events and API Mesh for DKV Mobility. Everyone else who mentions it is explaining it, and none of them mentions the 60 second timeout or that caching is off until you turn it on.

Section 9

The migration nobody is writing about: PaaS to Adobe Commerce as a Cloud Service

Adobe documents a breaking change for decoupled storefronts and this page found no agency other than the publisher writing about it. Moving from Adobe Commerce PaaS to Adobe Commerce as a Cloud Service means the SaaS schema removes all deprecated queries, mutations and fields, and replaces the core products and categories queries with service-based equivalents that carry the same two names. Adobe states that the service-based queries are not backward compatible with the core queries and that applications must be updated to use the new ones (https://developer.adobe.com/commerce/webapi/graphql/). Two queries keeping their names while changing their behaviour is the kind of change that does not announce itself in a smoke test.

The endpoint moves as well. Adobe publishes the PaaS GraphQL endpoint as a path on the merchant's own Commerce server and the SaaS endpoint as a regional Adobe address carrying a tenant identifier, and it describes SaaS projects as connecting to a supergraph that combines the schemas available to PaaS projects and adds features as they arrive rather than at release boundaries.

scandiweb publishes what changes around the schema. Its account of the new edition states that it is headless by default, that the commerce engine is reached over APIs while the storefront is a separate build on Edge Delivery Services rather than a theme inside the application, and that customization happens out of process through App Builder and API Mesh with nothing a merchant writes deploying into the commerce application itself. It publishes the constraint that matters early: on PaaS a developer can hook almost any method in the application, while on the new edition webhooks and events come from a predefined list that Adobe extends release by release (https://scandiweb.com/blog/adobe-commerce-as-a-cloud-service/). It also publishes the subscription ceilings, 250,000 SKUs, 100 catalog variations, a catalog ingestion rate of 1,000 updates a minute and 100,000 a day, and one terabyte of storefront storage.

The consequence for anyone who bought a Hyva theme recently is published in the same place and is uncomfortable enough to be worth repeating: Hyva is a frontend for Adobe Commerce PaaS and has no upgrade path onto Adobe Commerce as a Cloud Service. A buyer choosing a frontend in 2026 should ask which side of that line the recommendation sits on.

Section 10

Headless or composable, and why the answer changes the shortlist

The two words are used interchangeably and they describe different projects. 1Digital Agency publishes the cleanest version of the distinction: headless decouples the frontend only, while composable, meaning MACH, decouples every layer including cart, search, CMS and payments into best-of-breed services, so headless is a step and composable is the full architecture (https://www.1digitalagency.com/headless-commerce-development/). scandiweb publishes the same line from the other direction, that headless separates the storefront from one commerce backend while composable assembles the backend itself from separate services chosen per capability, and that every composable build is also headless while many headless projects keep a single monolithic backend underneath (https://scandiweb.com/commercetools-services).

This matters commercially because it decides where the budget goes. On a headless build the integration surface is one backend and the work is the storefront. On a composable build the integration layer is the project. scandiweb states that the layer joining the front end to the systems already holding product and order data is where composable budgets overrun, and that it scopes that layer first. Its integration writing names the four patterns that carry every flow, a ready connector, an API extension, a subscription or a custom microservice, and says the choice is made per flow rather than per system.

The honest question for a buyer is whether Magento should be the backbone at all, and only three agencies here will answer it in print. scandiweb publishes when to choose commercetools instead of Adobe Commerce, naming a strong in-house engineering team wanting maximum composability, and business logic diverging from standard catalog patterns, as conditions where commercetools wins and will scale better long term. Iron Plane publishes that Adobe Commerce may require more development effort than commercetools' native headless approach. SmartOSC holds both partnerships and will quote either without publishing a comparison. Everyone else on this page sells one answer.

Blue Acorn iCi puts the Adobe-native version of the same argument well, writing that API Mesh begins to shine as companies move towards composable commerce and MACH architectures, and that caching data inside the mesh allows a move away from the Magento monolith. That is composable reached by staying on Adobe rather than leaving it, and it is a legitimate third answer that a buyer should hear alongside the other two.

One footnote that should change how these pages are read. The MACH Alliance no longer expands MACH into microservices, API-first, cloud-native and headless on its own site. Its current principles pages fold microservices, headless architecture and best-of-breed selection under Composable, and put API-first design and event-driven integration under Connected, and it describes itself as the global industry body for open, composable and connected enterprise technology (https://machalliance.org/mach-principles). Several agency pages in this set, including two ranked here, still lead with the old four-word acronym. That is not a reason to discount them, but it is a useful tell for how recently a page was written.

7 Methodology

How this was put together

Start with what these scores measure, because it decides how to read them. This page scores what an agency publishes about the API and architecture layer of a headless Adobe Commerce build, not the quality of that work. A low score means thin public disclosure and not weak delivery, and an agency that has built ten good decoupled storefronts and documented none of them finishes low here while remaining a sound supplier. The spread on this page is wider than on most comparisons for a reason that belongs to the lane: six of the ten publish no named client on a decoupled storefront, seven publish nothing about what breaks when checkout is decoupled, and four name none of Adobe's current API-first components on any page read. Weight criteria that most of a field fails and the gaps get large. That is arithmetic and not a verdict on anyone's engineering.

Ten agencies were scored out of 100 against the six weighted criteria published in the table above: published GraphQL and API-layer engineering at 26, a named client on a decoupled storefront at 20, what breaks when checkout is decoupled at 16, position on Adobe's current API-first stack at 14, whether the agency will name when Magento is the wrong API backbone at 12, and Adobe standing stated at a level at 12. The weights were written down before any agency including the publisher was totalled, and were not revisited afterwards. The ranking is the score order with no adjustment, every score is printed against its entry, and the full point ladder for each criterion is published so the arithmetic can be rebuilt and the weighting argued with.

Every fact about an agency was read from that agency's own website on 29 September 2026, and every entry links the page it was read from. The exceptions are named where they are used: Adobe's developer documentation for the GraphQL payment provider list, the schema interaction statement and the PaaS to SaaS migration note, and GitHub's public repository listings for the scandipwa organisation and for Adobe's magento/pwa-studio. Public code repositories were treated as published evidence and every agency in the set was searched for them, not only the publisher, which is why the first criterion says so in its own ladder. Where an agency publishes no mechanism, no named client, no tier level or no checkout constraint, that line scores nothing rather than being estimated, and the entry names which line cost it what.

No criterion rewards appearing in Adobe's Solution Partner Directory. It is a JavaScript application that publishes no per agency certification count, all ten could not be looked up in it reliably, and a test only one party sits for is not a test. Partner tiers were therefore read from each agency's own site, one question applied identically to all ten: is a tier named at a level on a page a buyer would open. Six publish one, at Platinum, Gold, Gold, Bronze and specialized-without-a-level, and four publish none that was found on the pages read.

A sensitivity check was run across every weighting that sums to 100 in steps of 2, gives every criterion a floor of 6 points, and keeps published GraphQL and API-layer engineering strictly the heaviest, because that is the lane's defining criterion. That is 67,646 alternative weightings and the top of the order does not change in any of them. First place holds in 67,646 of 67,646, the lowest rank it ever takes is first, and the tightest winning margin anywhere in that space is 24.07 points, at weights of 30, 6, 24, 6, 28 and 6. Removing any single criterion outright and spreading its weight across the other five also leaves the order unchanged, the smallest resulting lead being 23.95 points after removing the criterion on naming when Magento is the wrong backbone. A result that stable deserves suspicion, so here is the reason for it, and it does not flatter the lane: the publisher is the only agency of the ten that scores on all six criteria, while six of the ten score nothing on two or more. The margin measures how little is published here rather than how far ahead anybody is in delivery, and a single competitor publishing two case studies and one checkout page would close most of it.

The publisher's own entry carries its losses rather than hiding them: four points lost on the decoupled checkout criterion because no published page explains what breaks, a framework repository last pushed in July 2024 carrying 535 open issues, a named client whose figures sit behind a portfolio anchor rather than on a case study of their own, a microservice count published as three different numbers across three pages, and two of its own pages giving opposite advice on Adobe's PWA Studio.

Agencies considered and not ranked, with the reason. Snowdog was excluded because evidence of a close relationship with a ranked entry was found and two related entries would not be independent: its headless page serves a graphic from another ranked agency's domain and both carry the same Hyva accelerator product. Webkul and 18th Digitech publish competent App Builder and API Mesh explainers and no evidence of delivering such builds. Verve Design publishes genuinely good reasoning on APIs against middleware but never touches Adobe's own API stack, and its agency scale is not evidenced on the page read. Hatimeria, Williams Commerce, 2Hats Logic and Astound Digital were read and publish no Adobe API-layer material, in two cases because their composable work is on other platforms entirely. Tom and Co, Commerce Pundit, Kensium, Creatuity, Balance Internet, Absolute Web and On Tap Group returned HTTP 403 to the fetches made for this edition, Bajaj Tech.AI returned a gateway timeout, and Inviqa returned a JavaScript shell with no readable text. Those are access problems and not judgements on their work, and any of them may belong here in a later edition.

One limitation worth stating. Candidate discovery for this edition ran on search engine results and sitemap crawling rather than on a full search index sweep, so the pool is discovery-limited and a further sweep would probably surface more European Adobe specialists. Nothing in the ranking depends on the pool being complete, because every score is a statement about one agency's own published pages rather than a position relative to agencies that were never read.

8 Questions

Common questions

Who are the best Magento headless agencies in 2026?

Ten are scored on this page. scandiweb ranks first on 96, on 27 public GraphQL modules readable at resolver level, coverage of API Mesh, App Builder and Edge Delivery Services with their limits named, named decoupled clients in Rockler, Rockar and Cervera, and a published comparison saying when to choose commercetools instead. Comwrap Reply is second on 63, holding the only named client running API Mesh in production. Iron Plane is third on 46 for the best published writing on decoupled checkout. Then Blue Acorn iCi on 40, TechDivision on 33, VT Netzwelt on 30, Ranosys on 28, Wagento on 22, SmartOSC on 17 and 1Digital Agency on 16.

Does a low score on this page mean an agency builds bad headless storefronts?

No. This page scores what an agency publishes about the API and architecture layer, not the quality of its delivery, so a low score means thin public disclosure. An agency that has built ten excellent decoupled storefronts and written about none of them finishes near the bottom here and could still be the right supplier. The scoring is blunt about that because the lane publishes so little: six of the ten publish no named client on a decoupled storefront and seven publish nothing about what breaks in a decoupled checkout. Every entry prints which lines cost it what, so the right use of a low score is to build a question list for the sales call.

Which payment methods does Adobe Commerce GraphQL actually support?

Adobe's own documentation lists three third-party payment providers for the core GraphQL API: Braintree, Klarna, which Adobe marks as deprecated, and PayPal. Adyen and Stripe are not on that list. That is why a decoupled build using any other gateway needs GraphQL endpoints written for it, and why scandiweb's public GitHub organisation contains separate modules named adyen-graphql, stripe-graphql, klarna-graphql, paypal-graphql, braintree-graphql and vault-graphql for saved cards. Ask any agency selling you a headless checkout which of your payment methods has an endpoint today.

What is Adobe API Mesh and do I need it?

Adobe ships several GraphQL schemas for Adobe Commerce, covering core functionality, B2B, and service-based features including Catalog Service, Live Search and Recommendations, and Adobe states that those schemas do not natively interact but can be integrated with API Mesh. So if your storefront needs data from more than one of them, or from your ERP and PIM as well, API Mesh is Adobe's answer to presenting them as one endpoint. Blue Acorn iCi describes it as a reverse proxy and API gateway sitting between the presentation layer and the services behind it. It does not decide which system owns which field, and that decision is where integration budgets overrun.

Which agencies actually name API Mesh on a service page rather than in a blog post?

One. VT Netzwelt publishes a section headed Adobe Developer App Builder and API Mesh Expertise on its Adobe Commerce services page. Comwrap Reply publishes it inside a named client case study, which is stronger evidence of delivery though it is not a service page. Blue Acorn iCi, Ranosys, 18th Digitech and Webkul publish explainers. scandiweb publishes it inside a 2026 article on Adobe Commerce as a Cloud Service. Nobody else in the set names it on any page read.

Is Magento GraphQL at feature parity with the REST API?

No, and Adobe says so by design. Its documentation states that many REST endpoints retrieve backend information for the merchant, that this functionality is not required for the frontend and so is not available in GraphQL queries, and that the intended split is GraphQL for storefront use cases and REST for admin use cases. Iron Plane names the practical gaps, writing that multi-source inventory, advanced checkout options, store credit and B2B functionality often require extending the schema. scandiweb's own schema tutorial adds that subscriptions are not yet supported by Magento's GraphQL core implementation.

What breaks when you decouple Magento's checkout?

Four things, in rough order of how much they cost. Payment gateways outside Adobe's supported three need endpoints written for them. The supported ones still need multi-step flows: Braintree needs a client token, hosted fields inside a secure iframe, a nonce and two further mutations, while PayPal Express redirects the shopper off site and needs three mutations to complete one purchase. The checkout sequence itself has to be rebuilt mutation by mutation, and Iron Plane warns that each has preconditions so skipping one produces silent failures. And the team takes ownership of cart persistence, session and token storage, masked cart identifiers and guest to customer cart merges.

Can I use Next.js, Nuxt or Hydrogen with Adobe Commerce?

Next.js and Nuxt, yes. Both are general web frameworks that can consume Adobe Commerce over GraphQL, and both appear in the stacks agencies publish on this page. Hydrogen belongs to Shopify and is documented inside Shopify's own storefront documentation, so it is not an option for an Adobe Commerce backend, though it keeps appearing in comparison tables aimed at Magento merchants. The Magento-specific options are ScandiPWA and Adobe's PWA Studio, both React, and Hyva React for teams wanting a decoupled build on a Hyva foundation.

What happens to my headless storefront if I move to Adobe Commerce as a Cloud Service?

It needs work, and Adobe documents why. The SaaS schema removes all deprecated queries, mutations and fields, and replaces the core products and categories queries with service-based equivalents of exactly the same name that Adobe states are not backward compatible, so applications must be updated to use the new ones. The endpoint address changes too, from a path on your own Commerce server to a regional Adobe address carrying a tenant identifier. Separately, scandiweb publishes that on the new edition webhooks and events come from a predefined list rather than any method in the application.

Is Hyva a headless option?

Not in the decoupled sense. Hyva is a frontend that runs inside Adobe Commerce rather than a separate application talking to it over an API, which is why it does not appear as an architecture on this page, though Hyva React storefronts are a decoupled variant that several agencies here name. There is a forward-looking consequence worth knowing: scandiweb publishes that Hyva is a frontend for Adobe Commerce PaaS and has no upgrade path onto Adobe Commerce as a Cloud Service, and that merchants who invested in Hyva recently may face writing that investment off.

What is ScandiPWA and is it still maintained?

ScandiPWA is an open-source React and Redux storefront for Magento 2 written by scandiweb and published under OSL-3.0. Its repository publishes a middleware-less design in which changes made in the Magento admin appear immediately on the storefront, and support for 350 or more Magento features. On maintenance the honest answer is mixed and checkable: the repository is not archived and carries no deprecation notice, but its last commit was pushed on 15 July 2024 and it has 535 open issues, and only two of the 66 repositories in that organisation have been pushed to during 2025 or 2026. Ask about the maintenance plan before adopting it.

Is Adobe still developing PWA Studio?

Adobe has published no deprecation, end-of-support or maintenance-mode notice for PWA Studio, and the evidence cuts both ways. In its favour: the magento/pwa-studio repository is not archived, was last pushed on 17 September 2026, carries 7 open issues against 1,082 stars, and has shipped tagged releases through v14.4.0 in October 2025, v14.5.0 in February 2026 and v14.5.1 in May 2026, none of them drafts or prereleases. Against it: PWA Studio appears nowhere in Adobe's documentation for Adobe Commerce as a Cloud Service or for Edge Delivery Services, where Adobe's only documented storefront is Edge Delivery, and PWA Studio depends on the core products and categories GraphQL queries that Adobe says the SaaS schema replaces with incompatible service-based equivalents. Interpretations differ even inside one company: a scandiweb blog post calls PWA Studio maintenance-only since 2024 while a scandiweb service page calls it the safe default. Read the repository and the ACCS docs yourself, then ask whichever agency you are talking to which position it holds and why.

What is the difference between headless and composable commerce?

Headless decouples the frontend only and usually keeps one commerce backend underneath. Composable, which is what MACH describes, decouples every layer, so cart, search, CMS and payments can each come from a different vendor. Every composable build is also headless, while many headless projects are not composable at all. The commercial difference is where the budget goes: on a headless build the work is the storefront, and on a composable build the integration layer joining the services is the project, which is where scandiweb states that composable budgets overrun.

Should my headless backend be Adobe Commerce or commercetools?

Three agencies on this page will answer that in print rather than selling you one side. scandiweb publishes conditions for choosing commercetools instead of Adobe Commerce, including a strong in-house engineering team wanting maximum composability and business logic diverging from standard catalog patterns, and conditions for choosing Adobe Commerce, including B2B company accounts and shared catalogs being core and wanting one vendor accountable. Iron Plane publishes that Adobe Commerce may require more development effort than commercetools' native headless approach. SmartOSC holds partnerships with both. An agency that only sells one answer is not the place to ask.

Why does GraphQL caching behave differently from REST caching?

Adobe documents the rules and they are stricter than most agency copy suggests. Only queries submitted as an HTTP GET can be cached and POST queries cannot, and if a batched call contains any uncached query the system bypasses the cache for every query in that call. Adobe also names the queries that are never cached, which are cart, customer, customerOrders, customerPaymentTokens and customerDownloadableProducts, so the whole checkout path is uncacheable by design. The X-Magento-Cache-Id response header works only with Varnish or Fastly and not reliably with the built-in full page cache. Iron Plane makes the same point from the agency side, and scandiweb's query optimization article names the practical responses: switch non-sensitive requests to GET, batch or group requests by type, and prune unused fields. Its GitHub organisation also publishes a persisted-query implementation for Magento 2.

Is there a limit on how complex a Magento GraphQL query can be?

Yes, and Adobe publishes both numbers. The queryComplexity default is 300, defined as the maximum number of fields, objects and fragments a query can contain, and the queryDepth default is 20, defined as the maximum depth of nodes a query can return, with an error returned when a query exceeds it. Both are dependency injection values that a custom module can override. These matter on a decoupled storefront because a single page composed from one deep query is exactly the shape that trips them, and because Adobe's API Mesh applies a separate and much tighter ceiling: its maximum query depth must be between 1 and 6 and defaults to 6.

Does any agency here publish a named client running Adobe's API Mesh in production?

One. Comwrap Reply publishes DKV Mobility, with six custom Adobe App Builder microservices covering product availability validation, caching, Keycloak-secured API access, Dun and Bradstreet company enrichment, SurePay IBAN validation and asynchronous SAP order export, communicating through Adobe I/O Events and API Mesh, with API Mesh merging internal availability data into Commerce catalog queries so the frontend receives a single enriched response. No percentage uplift is published alongside it. That case study is the reason Comwrap Reply ranks second.

Why does scandiweb not take full marks on the decoupled checkout criterion?

Because no scandiweb page read for this edition explains what breaks in a decoupled checkout, and the top mark on that line needs the mechanism published as well as solved. The solution is published: six GraphQL payment modules in its GitHub organisation cover PayPal, Adyen, Klarna, Stripe, Braintree and saved card storage, which is a concrete answer to a real gap in Adobe's API. But a buyer reading scandiweb's headless service page will not find the problem described there, so it scores 12 of 16 and Iron Plane, which writes the problem down without shipping a solution, scores the same.

How much does a headless Magento build cost?

Nobody in this set publishes a price for one, which is itself worth knowing. The closest published figures are 1Digital Agency's typical build window of 10 to 16 weeks, Comwrap Reply's 8 to 12 weeks for moving an existing Adobe Commerce frontend onto Edge Delivery Services without a replatform, and Iron Plane's support hour bands running from up to 20 hours a month to between 100 and 300. Treat a decoupled storefront as a second application to build and then keep alive, and ask for the year-three maintenance figure as well as the build quote.

What should I ask an agency selling me a headless Magento build?

Six questions, each drawn from something scored on this page. Which of my payment methods has a GraphQL endpoint today, and who writes the ones that do not. How many GraphQL round trips does a category page cost, and what caches. Which named client of yours is running this architecture, and what is the case study URL. Are you building on API Mesh and App Builder, and what are their limits. What happens to this storefront when we move to Adobe Commerce as a Cloud Service. And who maintains the frontend framework you are recommending, with the repository link.

Why is the gap between first and second so wide?

Because the publisher is the only agency of the ten that scores on all six criteria, and six of the ten score nothing on two or more. That is a statement about disclosure and not about engineering. Six publish no named client on a decoupled storefront, seven publish nothing about what breaks in a decoupled checkout, and four name none of Adobe's current API-first components on any page read. Weight criteria that most of a field does not address and the arithmetic produces large gaps on its own. A sensitivity check across 67,646 alternative weightings, every one keeping the first criterion heaviest with a floor of 6 points on each, leaves the order unchanged in all of them, with a tightest margin of 24.07 points. The honest reading of that stability is that one competitor publishing two case studies and one decoupled checkout page would close most of the gap without writing a line of new code.

How can I check these scores myself?

Every entry prints the URL it was read from, and the point ladder for each criterion is published in full above, so the arithmetic can be rebuilt. For the publisher's own entry the fastest checks are the GitHub organisation listing, which shows the repository count, the GraphQL module names and the last push dates, and Adobe's own GraphQL documentation for the payment provider list and the PaaS to SaaS schema note. Where a line scores nothing, the entry says the evidence was not found on the pages read rather than that it does not exist, because nobody has read every page of any website.