Skip to main content
BYOM’s documented developer integration is its Shopify MCP connector. It lets supported AI clients discover tools and work with a merchant’s authorised store context. These docs do not define a general public REST API or webhook subscription service.

​
Choose what you are connecting

The BYOM application is the merchant’s governed work environment. The Shopify connector exposes consented capabilities to an external AI client. The public documentation MCP lets a compatible client find and read these guides without store access. See Connect to the documentation MCP for its URL and current checks. You can configure both MCPs in one client, with distinct names such as BYOM docs and BYOM store. Keep their URLs, permissions and data separate. A successful documentation search does not mean a store is connected. The Shopify app is coming to the App Store. Contact BYOM about access and confirm that your AI client supports the connector.

​
The integration lifecycle

A client discovers the authorised resource and OAuth metadata, completes the merchant consent flow, initialises MCP and lists the tools visible to that grant. It calls the discovered tool with arguments matching the returned schema, then handles both protocol errors and tool-level failures. Do not hard-code an assumed list of available tools. Visibility depends on the grant’s data classes, write enablement and current account capabilities.
1

Confirm access and the task

Obtain the connector URL from the enabled account. Identify which store and data classes the integration needs. A client reading a product catalogue needs a different grant from one working with customer-service information.
2

Let the merchant authorise the client

Follow the resource and OAuth metadata. Use the supported PKCE flow; keep the merchant’s consent and resource binding intact. Do not collect a store password or put a bearer token into a conversation.
3

Negotiate and inspect

Initialise MCP, discover tools and call about_this_connection. Confirm the store and returned permissions before making a business-data request.
4

Prove a small read

Choose an advertised read tool, follow its input schema and inspect both the structured result and the error flag. Verify the answer against the intended record before adding a larger workflow.
5

Add proposals only where supported

If the client and grant support proposals, preserve the merchant-facing review interface. Check the eventual result and receipt rather than treating proposal creation as execution.

​
Keep the effect boundary

A model may read and prepare a proposal. Confirmation authority stays with the merchant-facing review interface. A client must not treat a model’s “yes” as a merchant’s approval. Show the returned status clearly. Prepared means there is work to review. Approved means the required decision was recorded. Executed, failed or partial describes the attempt’s outcome. Read the returned state instead of collapsing all three into “done”. The supported review surface may combine confirmation with execution; do not insert an invented second confirmation or bypass the one that is required.

​
Example: a catalogue-review assistant

Suppose a merchant wants help improving a product description. First confirm that the grant can read the relevant catalogue information. Retrieve the specific product through a discovered tool and ask the model to distinguish source facts from suggested wording. A list result may contain shortened text; use the specific record’s retrieval tool when the full text matters. Present the draft and its rationale. If a supported proposal tool is visible, the integration can prepare the change for the merchant’s review. If it is absent, retain the draft as internal work and explain the limitation. Never invent a direct write endpoint to complete the workflow.

​
What a useful integration must handle

  • The merchant cancels authorisation or chooses a different store.
  • A read is allowed but a proposal capability is not.
  • A provider permission is missing despite a valid BYOM grant.
  • A tool returns isError: true inside an HTTP 200 response.
  • Source data changes between a proposal and confirmation.
  • A timeout leaves the result uncertain.
  • Consent is revoked or the connection is disconnected.
Treat these as normal product states with clear recovery instructions. The errors guide explains which failures need a user action and which may justify a bounded retry.

​
UCP and commerce readiness

The Universal Commerce Protocol (UCP) describes commerce interactions such as product discovery and checkout. Each implementation supports its own capabilities. A catalogue assessment or successful product lookup does not establish checkout or payment support. For BYOM’s documented client integration, use the Shopify MCP contract above. Confirm any commerce capability against your enabled account and the relevant provider before building on it. These docs publish no UCP checkout or payment API. The product-content guide explains how to use available AI-shopping readiness evidence to choose a useful catalogue improvement. Reviewed 2 October 2026.