Wire API Mesh in Front of a Commerce App

Composes Commerce's own GraphQL API and this app's runtime actions into a single mesh schema. Two moves this skill covers: exposing a runtime action as a mesh source, and extending an existing Commerce type with a field resolved by delegating to that source.

This skill assumes general API Mesh knowledge (mesh.json anatomy, handler types, transforms, hooks, secrets, CORS, generic declarative/programmatic resolvers). If any of that is unfamiliar, load it from Adobe's own material first — see References — rather than guessing at syntax. None of that material covers extending an existing Commerce type via additionalResolvers (targetTypeName/sourceTypeName/requiredSelectionSet/sourceSelectionSet) or wrapping an aio-commerce-sdk runtime action as a mesh source — that's what follows.

Prerequisites

• aio plugins install @adobe/aio-cli-plugin-api-mesh is installed.
• If exposing a runtime action as a source, it's already built and deployed with a real, reachable HTTPS endpoint — a source pointing at an undeployed action fails opaquely.
• Check whether a mesh already exists for this workspace: aio api-mesh:get. "No mesh found" → you'll create; otherwise you're editing an existing mesh.json and will update.

Step 1 — Confirm schema shapes via introspection

Before writing additionalTypeDefs or additionalResolvers, introspect the Commerce (or other) GraphQL source you're extending. Don't assume a type/field name from memory or a similar-sounding convention — near-miss names produce a mesh that builds successfully but whose resolver never fires.