BigCommerce has very limited UCP adoption in our monitoring dataset — we’ve verified just 2 BigCommerce stores with live UCP implementations, representing under 0.1% of the 2,826 verified UCP merchants we track. The platform’s API-first architecture suggests it should produce clean UCP implementations, and the stores we’ve validated bear that out. With such a small sample, this guide is as much an analysis of what BigCommerce’s architecture makes possible as it is a report on observed data.
That's not accidental. BigCommerce has invested heavily in its API layer and headless commerce capabilities for years. When UCP arrived, the plumbing was already there. Merchants and developers who understand BigCommerce's architecture tend to implement UCP correctly because they're already thinking in terms of APIs, channels, and structured data.
The failure patterns in BigCommerce UCP implementations aren’t random. They cluster tightly around three areas: GraphQL token lifecycle management, channel routing misconfiguration, and headless deployments where the manifest is served from the wrong origin. Know those three failure modes and you’ve covered the most likely production issues.
This guide covers what BigCommerce provides natively, what the manifests actually look like across our monitored stores, where things break, and what it takes to configure your store for reliable AI agent commerce.
What BigCommerce Provides
BigCommerce does not ship native UCP support the way Shopify does. There is no first-party UCP toggle in the control panel. Instead, UCP is delivered through BigCommerce's App Marketplace — merchants install a UCP connector app that integrates with the platform's existing API surface.
This is architecturally different from Shopify's approach, and the difference matters. Because BigCommerce's REST and GraphQL APIs are already well-documented and production-ready, the connector app has a solid foundation to build on. The Storefront GraphQL API handles product discovery and variant resolution. The Management REST API handles order data and store configuration. The MCP transport layer sits on top of both.
Out of the box, a properly installed BigCommerce UCP connector exposes the same core MCP capabilities as Shopify: Checkout (cart management using the Server-to-Server Cart API) and Orders (order status via the V2 and V3 Management APIs). Catalog browsing is part of the UCP spec but is currently in draft status. The quality of each capability depends on which API version the connector uses and whether the relevant API scopes were granted during installation.
BigCommerce's channel-aware architecture is the defining structural characteristic for UCP. Every sales surface in BigCommerce — storefronts, POS, marketplaces, headless frontends — is a channel. Agent commerce is treated as its own channel, which is the correct abstraction. This means a well-configured BigCommerce store can route agent requests to a dedicated channel with its own pricing, catalog visibility, and checkout configuration, completely separate from the standard storefront.
The manifest at /.well-known/ucp is served through BigCommerce's custom pages feature or injected via the Script Manager, depending on how the connector app was configured. Both approaches work. The Script Manager approach is more common in practice and generally more reliable across theme updates.
The Manifest: What We See Across Monitored BigCommerce Stores
BigCommerce manifests are among the more consistently structured in our dataset. The connector app handles manifest generation, and its output is predictable — which makes deviations easier to spot when they occur.
The protocol version declaration is generally current on BigCommerce stores that installed the connector recently. The risk window is stores that have been running UCP for more than a few months without updating the connector app. BigCommerce's App Marketplace doesn't enforce automatic updates, so stores on older connector versions can fall behind the current protocol specification.
The capabilities array on a well-configured BigCommerce manifest should include dev.ucp.shopping.checkout, dev.ucp.shopping.discount, and dev.ucp.shopping.fulfillment at minimum. Stores using BigCommerce's B2B Edition — which adds company accounts, price lists, and purchase orders — should also declare B2B capabilities, but many don't. B2B Edition stores often have manifests that undersell their capabilities, causing agents to fall back to simpler B2C workflows on stores that could support negotiated pricing and purchase order flows.
The transport configuration is where BigCommerce manifests diverge most from Shopify. Shopify manifests reliably declare a single MCP endpoint. BigCommerce manifests can declare multiple transport paths depending on how the connector app routes different request types — some using the REST API, some using the GraphQL Storefront API. This is fine when it's intentional and correctly declared. It becomes a problem when the GraphQL transport endpoint carries an access token that's embedded in the manifest and subject to expiration.
The payment handlers section reflects BigCommerce's broad payment ecosystem. Native support for PayPal, Stripe, Braintree, Square, Adyen, Amazon Pay, and dozens of regional gateways means a well-configured manifest has a rich payment section. When merchants add or remove payment providers without triggering a manifest re-sync, the payment section silently drifts from reality — one of the most common issues we flag on BigCommerce stores.
For stores using Multi-Storefront (MSF), each storefront can and should have its own manifest. A BigCommerce instance running three storefronts — say, a retail brand, a B2B portal, and a regional market — needs three distinct UCP configurations. A common MSF mistake is having only the primary storefront with a current manifest, while secondary storefronts are either missing UCP entirely or serving a manifest copied from the primary with incorrect endpoint URLs.
Common Manifest Issues We Flag
The most common issues we’ve identified in BigCommerce UCP configurations are: expired GraphQL Storefront API tokens embedded in manifest transport declarations (the token was valid at install time but rotates on a schedule the connector app doesn't handle automatically), stale payment declarations after provider changes, MSF storefronts with missing or misrouted manifests, headless deployments where the manifest origin doesn't match the storefront domain, and undersized capabilities arrays on B2B Edition stores.
The GraphQL token issue deserves special mention because it's the failure mode most likely to affect you without warning. The token appears valid when the manifest is fetched — the JSON is well-formed, the endpoint URL resolves — but when an agent attempts a product search using the declared GraphQL transport, the 401 response is silent from the manifest's perspective. Monitoring tools that only check the manifest structure won't catch it. UCP Checker's runtime checks do.
Runtime Performance: Competitive With Shopify, Architecture-Dependent
BigCommerce is a managed SaaS platform, which means its baseline performance profile is comparable to Shopify — and significantly more consistent than self-hosted platforms like Magento or WooCommerce on variable hosting.
Across the 2 BigCommerce stores in our dataset, MCP tool call response times were 729ms and 894ms — significantly slower than Shopify’s median of 146ms. Our sample is too small to draw strong conclusions about the platform’s typical performance range, but both stores run on managed SaaS infrastructure, so the 729–894ms range likely reflects the overhead of BigCommerce’s API routing architecture. The GraphQL Storefront API is generally faster for product discovery, while REST-backed operations like checkout and order management tend to add additional latency.
Headless BigCommerce deployments — those using Next.js, Gatsby, or other frontend frameworks decoupled from the Stencil theme engine — add a layer of variability. The performance of the decoupled frontend itself doesn't affect MCP response times directly, but it can affect manifest availability and origin resolution. Headless stores that serve the manifest from the frontend origin rather than the BigCommerce-managed origin sometimes get different caching behavior than expected.
Tool availability on well-configured BigCommerce stores is high. When we run tools/list against stores with current connector versions and valid API tokens, the core tools are available. The failure mode is specifically those stores with expired GraphQL tokens — they pass manifest validation but fail tool availability checks at runtime.
Checkout completion rates on BigCommerce are competitive, with one important caveat: stores using BigCommerce's Optimized One-Page Checkout (OPC) with custom modifications introduce the same class of problems we see on WooCommerce stores with heavily-modified checkout pages. Standard OPC configurations work correctly with agent checkouts. Custom fields added via checkout scripts can break the automated flow if they're configured as required inputs with JavaScript validation that the MCP checkout tool can't satisfy.
Configuration Checklist
Based on our monitoring data, here are the five steps that separate BigCommerce stores that perform reliably in agent sessions from stores that pass the basic check but fail in production.
First, install the UCP connector app and complete the full API scope grant. Partial installations — where the connector was authorized with a reduced API scope to limit access — are a consistent source of checkout and order tool failures. The connector needs read/write access to carts, checkouts, and orders. Restrictive scope grants will produce a valid manifest with tools that silently fail on specific operations.
Second, check your GraphQL Storefront API token lifecycle. If your UCP connector uses an embedded GraphQL token in the manifest transport declaration, find out how that token is rotated and whether the connector handles rotation automatically. If it doesn't, set a calendar reminder to re-authorize the connector before the token expires. Then run a check at ucpchecker.com/check immediately after rotation to confirm the new token is correctly propagated.
Third, if you're running Multi-Storefront, configure UCP on each storefront independently. Don't copy the primary manifest to secondary storefronts and assume it will work. Each storefront has its own channel ID, its own API endpoints, and potentially its own payment configuration. The manifest for each storefront needs to reflect its specific channel context.
Fourth, test checkout completion on your specific configuration. Run a real agent session from product discovery through to order confirmation. If you have custom checkout scripts, loyalty integrations, or B2B pricing logic, test explicitly with those active. The standard manifest check won't catch checkout-layer failures — only a real session will.
Fifth, set up UCP Alerts. BigCommerce connector app updates, payment provider changes, and API credential rotations can all silently modify your manifest or break your transport. Alerts give you visibility when something changes so you can investigate before agents encounter the failure in a live session.
Multi-Storefront and Channel Considerations
BigCommerce's Multi-Storefront feature is architecturally similar to Magento's multi-store capability in its complexity, but delivered in a managed SaaS context that removes most of the infrastructure headaches. What remains is the configuration challenge: each storefront is an independent UCP surface that needs its own manifest, its own API scope grants, and its own channel routing configuration.
Channel routing is the core concept to understand. In BigCommerce's architecture, every request is associated with a channel. The UCP connector needs to map agent requests to the correct channel — typically the storefront channel the merchant wants agent commerce to flow through. When this mapping is misconfigured, agents may receive responses scoped to the wrong storefront: incorrect catalog, incorrect pricing, incorrect currency, potentially even a test store environment.
Three common channel routing failure patterns can appear in MSF deployments. The first is agents hitting the default channel rather than a configured agent commerce channel, resulting in catalog responses that include items not intended for agent-driven sales. The second is currency mismatch: a storefront configured for EUR pricing routing agent requests through a USD channel, producing pricing responses that agents accept but buyers see differently. The third is the B2B channel problem — agents authenticated as guest users being routed to a B2C channel when the merchant intended them to access B2B pricing.
If you're running MSF, the right approach is to create a dedicated channel for agent commerce and configure the UCP connector to route all MCP requests through it. This gives you explicit control over what agents can see, buy, and pay — and isolates agent traffic from your standard storefront analytics so you can measure it separately.
For headless BigCommerce deployments, the manifest origin question requires explicit attention. If your frontend is served from shop.yourbrand.com but your BigCommerce-managed origin is yourbrand.mybigcommerce.com, agents discovering your store need to find the manifest at the right domain. Typically this means the manifest should be served from the customer-facing domain, not the BigCommerce subdomain. The connector app can usually be configured to support this, but it needs to be set up deliberately.
Common Failure Modes
Four failure patterns come up repeatedly in our BigCommerce monitoring data.
GraphQL Storefront API token expiration. This is the most common and the most invisible. The UCP connector embeds a GraphQL access token in the manifest transport declaration at installation time. When that token expires — and all Storefront API tokens eventually expire — the manifest continues to look valid from the outside. Agents fetch it, parse the transport configuration, and attempt product queries using the embedded token. The 401 response is returned at the API layer, not the manifest layer. Manifest-only validation tools report no problem. Your store silently fails every product discovery request. The fix is to rotate the token and update the connector configuration, then verify the manifest reflects the new token. If your connector doesn't handle this automatically, you need a process to catch it before agents do.
Channel routing sending agent requests to the wrong storefront. This produces some of the hardest-to-diagnose failures we encounter in monitoring. The manifest is valid. The API endpoints respond correctly. Agents complete sessions and produce what look like successful checkouts. But the orders land on a different storefront than expected — a test channel, a marketplace channel, or a secondary storefront — and the fulfillment team never sees them. If your BigCommerce instance has multiple channels, explicitly configure and test the channel your UCP connector routes to. Don't assume it defaults to the right one.
Optimized One-Page Checkout conflicts with custom scripts. BigCommerce's OPC is well-suited to agent checkouts in its standard configuration. The problems arise with custom checkout scripts that add required fields — loyalty membership IDs, company account selectors for B2B stores, custom gift options — that the MCP checkout tool can't populate because they require JavaScript interaction or aren't exposed in the Server-to-Server Cart API. Agents that reach the final checkout step and encounter an unresolvable required field will abort the transaction. Audit your checkout scripts for required fields before going live with UCP.
Headless deployments serving the manifest from the wrong origin. Headless BigCommerce stores — those using Next.js or similar frameworks decoupled from Stencil — sometimes misconfigure which domain serves the UCP manifest. If the manifest is served from the BigCommerce-managed subdomain but agents discover the store at the custom domain, the manifest origin doesn't match the store's public identity. Some agents treat this as a trust failure and won't proceed. Ensure your manifest is served from your primary customer-facing domain and that the transport endpoint URLs in the manifest use the same domain.
Product Feed Best Practices
BigCommerce's product data model is one of the more capable in the market — native support for variants, custom fields, metafields, and the Catalog API's structured product hierarchy means there's no shortage of data to work with. The challenge is exposing it correctly through the UCP layer.
Use metafields for agent-relevant product attributes. BigCommerce's metafields API lets you attach structured key-value data to products, variants, and categories. For agent commerce, this is the right place to put attributes that matter for agent decision-making but don't fit neatly into standard product fields: care instructions, compatibility information, sizing notes, assembly requirements. Agents that can access metafield data make better recommendations and have lower clarification rates. Ensure your UCP connector is configured to expose product metafields in its Discovery tool responses.
Keep variant complexity manageable. BigCommerce supports up to 600 variants per product, which is a product management feature that becomes an agent commerce liability when used carelessly. An agent attempting to resolve a specific variant from a product with dozens of option combinations across three dimensions is doing significantly more work than one navigating a product with a clean, well-structured option set. For your highest-traffic products, audit the variant matrix for clarity — agents and humans alike navigate them better when options are logically structured.
Set accurate stock levels and availability signals. BigCommerce's inventory tracking is granular and reliable when maintained. UCP agents rely on the availability signals returned by the Catalog API to make add-to-cart decisions. Products shown as in-stock that fail at checkout — because the inventory wasn't updated after a bulk sale, or because stock tracking was disabled for a product category — produce failed agent sessions and degraded trust in your store as a reliable agent commerce destination.
Configure multi-currency correctly per channel. Unlike WooCommerce, which requires plugins for multi-currency, BigCommerce has native multi-currency support built into its channel architecture. But it requires explicit configuration per channel. If your agent commerce channel isn't configured with the correct transactional currency — the one you actually want agent purchases denominated in — you'll get currency mismatch issues at checkout. Verify this in your channel settings before enabling UCP agent traffic.
Structured data on storefront pages. For stores using Stencil themes, ensure your product pages include Schema.org Product markup. This creates a secondary discovery path for agents that discover products through web crawling before connecting via MCP. The markup should include product name, description, price with currency, availability, brand, SKU, and image URLs. BigCommerce's Stencil framework makes this straightforward to implement — and it serves double duty as structured data for traditional search engines.
What's Coming
BigCommerce's API-first philosophy positions it well for the next generation of UCP capabilities. Two developments are particularly relevant to BigCommerce merchants planning their agent commerce roadmap.
The first is B2B Edition integration with UCP. BigCommerce's B2B Edition — with its company accounts, price lists, and purchase order workflows — is an underdeveloped UCP surface. Most B2B Edition stores we monitor aren't exposing their B2B capabilities through UCP at all, which means agents are interacting with them as generic B2C stores. As UCP's B2B capability declarations mature and connector apps update to support them, BigCommerce B2B Edition stores have significant upside from exposing negotiated pricing and account-aware purchasing to AI buyers.
The second is webhook-driven manifest updates. BigCommerce's webhook infrastructure is robust enough to trigger automatic manifest refreshes when catalog, pricing, or payment configuration changes. Some advanced implementations already take this approach — manifest changes propagate within minutes of a store update rather than waiting for a manual re-sync or scheduled job. This will likely become standard practice as the connector app ecosystem matures and best practices solidify.
We track emerging capability adoption across all platforms through our stats dashboard. The BigCommerce segment is smaller than Shopify's but its quality distribution is a useful leading indicator of what well-implemented UCP looks like in practice.
Check Your Store
If you're running a BigCommerce store and haven't verified your UCP configuration, run a check at ucpchecker.com. The check validates your manifest structure, protocol version, and capabilities declaration — and our runtime checks will surface GraphQL token issues that manifest-only validators miss.
If you're running Multi-Storefront, run the check against each storefront domain separately. A passing result on your primary storefront doesn't tell you anything about the configuration state of your secondary storefronts.
Once you're in our directory, set up UCP Alerts so you're notified when we detect a change in your manifest. Token rotations, connector updates, and payment configuration changes can all silently modify your manifest. Catching those changes before agents encounter them is the difference between managed UCP health and discovering problems through failed sessions.
And if you want to see how real AI agents experience your BigCommerce store — including whether that GraphQL token is actually working end-to-end — UCP Playground lets you run live agent sessions against your store. It's the fastest way to validate that your channel routing is correct and your checkout flow completes without interruption.
References & Official Resources
- Commerce Supports Universal Commerce Protocol — BigCommerce’s parent company endorses UCP at NRF (January 2026)
- Universal Commerce Protocol (UCP) Explained — BigCommerce Blog
- Commerce Investor Relations: UCP Announcement — Plans to offer buying directly across Google AI surfaces
- Google: New Tech and Tools for Retailers in an Agentic Shopping Era
- UCP Specification — ucp.dev
Further Reading
- The First Fully Autonomous AI Agent Purchase Through UCP — what an end-to-end autonomous transaction looks like in practice
- UCP Now Supports Identity Linking — especially relevant for B2B Edition stores with company accounts and price lists
- The State of Agentic Commerce — March 2026 — BigCommerce adoption data in context with the broader ecosystem
- Why We Built UCP Playground — test your BigCommerce store with real agent sessions across five models
Related Platform Guides
Exploring UCP across other platforms? These guides cover what we’ve learned about each platform’s implementation:
Top comments (0)