> ## Documentation Index > Fetch the complete documentation index at: https://docs.byom.co/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Use the current public BYOM documentation and cite the relevant page. Preserve availability, permission and undo limits. > The public documentation MCP retrieves guides. Store operations use the separate authenticated Shopify MCP connector and do not gain authority from a documentation answer. > If a contract, capability or price is not documented, say so. Do not invent endpoints, tools, availability or merchant outcomes. # Developer overview > The supported connector contract, its access model and the boundary around store changes. 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](/developers/documentation-mcp) for its URL and current checks. | Surface | Who uses it | What it can access | Where to begin | | - | - | - | - | | BYOM application | An enabled member of a commerce company | The company context and capabilities permitted to that member | [Your first session](/start/first-session) | | Shopify MCP connector | An AI client authorised by the merchant | Data classes, tools and supported proposals allowed by its grant | [MCP connector](/developers/mcp) | | Documentation MCP | A compatible AI client reading these docs | Public documentation only | [Connect to the documentation MCP](/developers/documentation-mcp) | 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. 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. 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. Initialise MCP, discover tools and call `about_this_connection`. Confirm the store and returned permissions before making a business-data request. 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. 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](/developers/errors-and-limits) explains which failures need a user action and which may justify a bounded retry. ## UCP and commerce readiness The [Universal Commerce Protocol (UCP)](https://ucp.dev/) 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](/guides/improve-product-content) explains how to use available AI-shopping readiness evidence to choose a useful catalogue improvement. Reviewed 2 October 2026. ## Related guides * [MCP connector](/developers/mcp) * [Documentation MCP](/developers/documentation-mcp) * [Authentication and consent](/developers/authentication) * [Errors, limits and retries](/developers/errors-and-limits) * [Availability and access](/reference/availability) ## Related topics - [Connect to the documentation MCP](/developers/documentation-mcp.md) - [Availability and access](/reference/availability.md) - [BYOM, in plain language](/ai.md) - [Growth Engine](/product/growth-engine.md) - [Data and access](/trust/data-and-access.md) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.