Platform implementation guide

Adobe Commerce / Magento: build a controlled agentic-commerce path

Select the Adobe Commerce API surface from the merchant's actual deployment model, then validate catalog, cart and order behavior without treating API access as proof of agent-protocol support.

Official sources reviewed 2026-08-27. This date records the documentation review, not a test of a specific merchant store.

Capabilities confirmed in official documentation

• PaaS projects can use separate core, B2B and service GraphQL schemas. Adobe says these schemas do not interact natively, although API Mesh can integrate them.
• The SaaS supergraph combines schemas, removes deprecated fields and replaces the core products and categories queries with service-based equivalents that are not backward compatible.
• GraphQL schema introspection is available, and Adobe publishes a Commerce API playground that runs selected queries against Luma sample data.
• The PaaS GraphQL checkout tutorial covers customer and guest order placement, but Adobe states that GraphQL does not perform backend tasks such as invoice or shipment management.
• A customer token can be generated through GraphQL. An admin token must be generated through REST; the documented defaults are one hour for customer tokens and four hours for admin tokens.
• Adobe Commerce as a Cloud Service requires Adobe Identity Management Service access tokens for REST requests, including interactive and server-to-server workflows.

Implementation sequence

1. Record whether the merchant runs PaaS, on-premises or SaaS before choosing endpoints, schemas or authentication. Do not reuse a PaaS products query unchanged after a SaaS migration.
2. Expose only current, customer-visible catalog fields for the selected store view. Keep staged content and admin tokens outside a shopper-facing agent.
3. Carry the selected variant, store scope, locale, currency and buyer state from discovery into the cart, then refetch price, availability, promotion, tax and shipping before order placement.
4. Use customer or guest authorization for shopper actions. Reserve IMS or admin credentials for narrow server-side operations with separately recorded scopes and owners.
5. Separate order placement from invoice, shipment, cancellation and refund processing. Route each post-order task to the documented backend workflow instead of implying that GraphQL checkout completes it.

Scenarios to test before claiming support

• A PaaS core products query is sent to a SaaS service-based schema and must fail visibly rather than silently dropping fields.
• A promotion or inventory value changes after discovery. The cart must show the recalculated result before buyer confirmation.
• A customer token expires during checkout and the client must recover without switching to an admin credential.
• A cart or place-order mutation is replayed after a timeout. The implementation must reconcile the cart or order state before retrying.
• The same product is queried under a different store view, locale or currency and the response must not reuse the previous context.
• A post-order request attempts to create an invoice or shipment through the shopper GraphQL flow and is routed to the appropriate backend process.

Evidence to retain from the test

• Record the deployment model, Adobe Commerce version, GraphQL schema or REST reference, endpoint and store scope used by the test.
• Retain redacted request and response pairs for product retrieval, cart totals and order placement, including timestamps, product and variant IDs, cart ID and resulting order identifier.
• For every retry or token-expiry test, compare the expected object count and state with the obtained cart or order state. A successful HTTP response alone is not sufficient evidence.

What the documentation does not establish

• The reviewed Adobe documentation does not establish native ACP, UCP, AP2 or MCP support for Adobe Commerce.
• The Commerce API playground uses Luma sample data; success there does not prove a merchant's schema, permissions, inventory or checkout behavior.
• A working catalog query does not establish order placement, payment, invoice, shipment, refund or production eligibility.
• The exact SaaS or PaaS capabilities of a merchant remain unverified until its live schema and authorized test environment are inspected.

Evidence boundary

Adobe's deployment models and schemas differ materially. Publish only the merchant capabilities that were observed in the correct environment and tested from discovery through the intended order boundary.

Use the public signal scanner for a limited external check, then run the test cases above in a controlled environment. Review common failure modes before extending credentials or payment access.