Bridge AI.

Endpoint per store

1

Shopify tools

Value

PKCE + consent screen

OAuth 2.1

On every plan

$0

• Action — your storeLiveYour catalogue, orders, pages, themes and the whole Admin API surface your scopes allow. The merchant's own data, read live.
• Intelligence — the marketLiveThe canonical Shopify store graph (rank a category, look up a domain, find similar stores, inspect a stack, read winning angles) plus the forward-looking layer: lifecycle stage, breakout probability, saturation risk and a 30-day traffic forecast, backtested with precision and recall tracked per model and horizon. The revenue estimate and the opportunity score are heuristics and are not backtested.

Ask what is working across the market, then ask what your own store does about it: without the agent changing connection, or losing the thread.

• MCP — your AI clientClaude, ChatGPT, Claude Code, Cursor. Read the store from the assistant you already have open, over OAuth or a static key.
• API — your own codeScoped keys for usage and Intelligence reads, plus the extension select relay. Environments, expiry and allowed domains per key. Not a GraphQL API and not an SDK that creates Shopify stores.
• Dashboard — @Atlas and the agentsThe one surface where writes happen, each behind the approval flow. Same store, same connector, a human in the loop.
• UCP — agent negotiationEvery store we probe can read /.well-known/ucp-agent. Catalog search and lookup only. No cart, no checkout, no secrets. It is how agents negotiate what we can answer before they hit the MCP.
• BoostEcom Spy — the Chrome extensionSelect any DOM element on the open web and relay it into the platform tab. The extension never carries credentials: the signed-in browser tab does the write.

A Custom App is installed by the merchant, so it asks for exactly the scopes that merchant ticks: it is not capped by what a public app is allowed to request, and Shopify does not put it through the review a public app needs to touch theme files. Your scopes are the ceiling. We add none of our own.

Bridge AI is a remote MCP server. Every store you connect to BoostEcom gets its own endpoint at /api/mcp/<STORE_ID>, speaking Model Context Protocol over streamable HTTP. Any MCP-aware client — Claude, ChatGPT, Cursor, or something you wrote yourself: can discover it, authorize against it and call its tools.

Your Shopify credentials never leave our servers. The client holds a BoostEcom token; we hold the Custom App token, encrypted at rest and refreshed on our side. Revoke the BoostEcom token and the client is out, having never seen a Shopify secret. The same Bridge surface also covers the live OAuth connectors (Google, Meta, Klaviyo, Figma, Notion) and BoostEcom Spy that relays selections into the platform tab.

• ClaudeOAuth 2.1Claude does the discovery itself. You paste one URL and approve a consent screen: there is no client id to create, no secret to store, no config file to write.
• ChatGPTOAuth 2.1ChatGPT custom connectors speak the same protocol as Claude: one URL, OAuth discovery, a consent screen you approve.
• Claude CodeStatic keyA terminal client wants a config file, not a browser. Generate a static key, declare the server, or commit the config so the whole team gets it.
• CursorStatic keyCursor reads an mcp.json. Point it at your store endpoint with a static key and the tools show up in the composer.

• Anything the Admin API can read, the passthrough reads: metafields, metaobjects, markets, translations, publications, inventory levels, fulfilment orders, discounts, customer segments, files.
• Your Custom App scopes decide what succeeds, and Shopify enforces that per query. We add no allowlist of our own on the read path.
• Shopify's own `cost` and `throttleStatus` come back with the data, so a model paces itself against the real bucket instead of guessing at it.
• A Custom App is installed by the merchant, so it asks for exactly the scopes that merchant ticks: it is not capped by what a public app is allowed to request.

Measured on one merchant's Custom App: a store that grants fewer scopes gets fewer. The structural point holds regardless: a Custom App is installed by the merchant, so it can request what a public app is not allowed to.

1. Your client calls the endpoint with no token and gets a 401 carrying a WWW-Authenticate header (RFC 9728).
2. It follows that header to the protected-resource document, which names this origin as the authorization server.
3. It reads the authorization-server metadata (RFC 8414) to find the register, authorize, token and revocation endpoints.
4. It identifies itself with a Client ID Metadata Document, a client_id that is an https URL we fetch and verify (MCP 2026-07-28). Clients still on dynamic registration (RFC 7591) are accepted too. Public client either way, no secret issued, PKCE S256 mandatory.
5. You land on a consent screen listing the permissions in plain language (catalogue, orders, themes, analytics) with only the ones your Custom App can actually satisfy shown, and you approve or deny.
6. The client exchanges its one-time code for an access token valid one hour, plus a refresh token that rotates on every use.
7. If a tool needs a permission your token does not carry, the call comes back 403 with the exact scope to request: the client re-authorizes for that one scope and retries, instead of you starting over.
8. Disconnect the integration and the client calls the revocation endpoint (RFC 7009): the token dies on our side too, not only in the client's memory.

Tokens are bound to a single store: one issued for store A is refused on store B, and organization membership is re-checked on every call. Everything is stored as a SHA-256 hash, we never keep a token we could read back.

GET https://www.boostecom.app/oauth/authorize
  ?response_type=code&client_id=<CLIENT_ID>
  &resource=https://www.boostecom.app/api/mcp/v1/<STORE_ID>
  &scope=boostecom:store.read boostecom:catalog.read
  &code_challenge=<S256>&code_challenge_method=S256

Two gates, and both must pass: the scope you approved for this client, and what your Shopify Custom App can satisfy. A permission Shopify would refuse is never offered on the consent screen in the first place. Tokens issued before this catalogue existed carry the legacy mcp scope and keep every Shopify tool they already had. It never confers a scope on a BoostEcom system: those are granted only by asking for them by name.

• Read-only by designQueries run. Every mutation is refused at the relay, and a document we cannot prove is read-only counts as a write. Writes go through the dashboard chat, where the approval flow lives.
• Your scopes are the ceilingThe tool list is derived from the scope string Shopify itself returned when you connected the Custom App. Not a setting we picked, a mirror of what you granted.
• Every attempt journaledRefused or executed, each write attempt lands in your audit log with its risk class, the auth mode and the mutation names. Variable names are kept; their values never are.

Custom plans run uncapped. A 429 names the plan, the limit it hit and what to do about it.

• State of the storeOne runAudit call returns shop, themes and a product sample together, so the model reasons over the whole store instead of stitching four requests.
• Catalogue questionsWhich products are still drafts, what is out of stock, which handles collide: answered against live data, not a stale export pasted into a chat.
• Anything the Admin API readsMetafields, markets, translations, publications, fulfilments: one passthrough tool, with Shopify's own cost and throttle numbers returned so the model paces itself.
• Reporting where you workSummarise the week's orders in the client you already have open, without exporting customer data into a spreadsheet first.

• In-band approval: instead of refusing a mutation, the server suspends it, shows you the diff, and resumes the same tool call once you approve, so the agent never loses its thread.
• Dry-run first: every write tool returns the affected objects, the before/after values and a risk class before anything is applied.
• Composite audits: launch readiness, tracking, checkout and revenue-leak checks returned as typed findings rather than prose.

• Read-only by design. Queries run; every write is refused and journaled. Writes happen in the dashboard chat, where the approval flow lives.
• Your Custom App scopes are the ceiling. A store connected for products only never sees the order or theme tools at all.
• One request, thirty seconds. Long work belongs in a workflow, not in a tool call.
• MCP and the Intelligence REST API are the supported surfaces. There is no first-party GraphQL API and no npm SDK, on purpose: two more contracts to keep in sync is two more ways to drift.
• Rate limits are per organisation. Stores in the same organisation share one budget.