MCP for affiliates

Early access — live. The affiliate connection is live in production end to end: the OAuth flow routes to the affiliate dashboard, its approval screen has shipped, the /v1/affiliate endpoints are live, and the hosted MCP server exposes the dev-store tools, so an assistant can create a dev store, select it, build inside it and hand it over without leaving the conversation. What gates it is the affiliate programme, not a beta list — see What is live, and what gates it.

Let an affiliate — a member of Orbit's affiliate programme who builds stores for clients — connect an AI assistant to their own sandbox stores, build inside them, and hand a finished store to the client who then picks a plan and pays.

A note on the name. Earlier builds of this connection family spelled it partner in the API — Shopify's word for the build-a-store-and-hand-it-over motion. On Orbit "partner" is the realm of plugin and theme developers, so the family is now spelled affiliate throughout (McpConnectionType.AFFILIATE, the /v1/affiliate/* paths). The person who mints it is an affiliate, the consent screen is the affiliate dashboard (affiliates.myorbitcommerce.net), and it has nothing to do with the partner dashboard.

Who this is for

Orbit's affiliate programme gives affiliates dev stores: full stores they create for free, build out for a client, and transfer when the work is done. The client takes ownership, chooses a plan and pays immediately (there is no trial on a handed-over store); the affiliate earns commission on what the client then pays.

The affiliate connection puts that lifecycle behind an MCP connection. Where a merchant connection is bound to one store a merchant already runs, an affiliate connection is bound to the affiliate, carries no store of its own, and works on whichever of the affiliate's dev stores it has made active.

What a dev store is

A dev store is a complete store with one flag set: is_dev_store. That flag is enforced across the platform, not just displayed:

• No payments. Checkout cannot take money and the store cannot connect a payment account. Everything else — catalogue, theme, pages, navigation, settings — works exactly as it will after handover.
• Not indexed. The storefront is reachable for review but marked noindex.
• Not counted. Dev stores are excluded from platform metrics.

A dev store belongs to exactly one affiliate and moves through three states:

The commission record is written only when a transfer completes and the client starts paying — nothing accrues while a store is still a sandbox.

Authorisation

The same OAuth 2.1 + PKCE flow as a merchant connection, against the same authorization server, with one difference: the address. An affiliate pastes the affiliate endpoint into their assistant:

https://api.myorbitcommerce.net/mcp/affiliate

The affiliate dashboard shows this address under Settings → AI assistants, with the one-line claude mcp add command for Claude Code; in claude.ai or Claude Desktop it is added as a custom connector. The bare /mcp address is the merchant endpoint: pasting that sends the approval to the store dashboard's login, which an affiliate with no store cannot pass.

The path is what makes the connection an affiliate one, before anyone has signed in anywhere. Its discovery document (/.well-known/oauth-protected-resource/mcp/affiliate) advertises the affiliate scope catalogue, devstore:* included, and the client sends the address back as the RFC 8707 resource when it starts the flow. The authorization endpoint reads either signal and sends the user to the affiliate dashboard's consent screen instead of the store dashboard's. A request that arrives at the bare /mcp address with an explicit devstore:* scope is routed the same way. Both signals only pick which screen sees the request; what is actually approved is decided on that screen and re-derived server-side.

The affiliate signs in to the affiliate dashboard, sees the client's name from the server's own registration record, and approves a permission tier. The resulting token is bound to the affiliate, not to any store.

Ownership is re-checked on every request: the connection may only see and manage its own affiliate's dev stores, and a store that has been transferred or closed stops answering immediately, even mid-session.

Permission tiers

Affiliate consent uses the same three tiers as the merchant screen. The merchant-surface scopes keep the tier they have there; the four dev-store scopes are tiered on the same rule — what does the operation actually do?

With the merchant scopes included, an affiliate tier-3 grant carries 207 scopes (80 at tier 1, 8 at tier 2, 119 at tier 3). The dev-store scopes are never offered on a merchant consent screen and cannot be held by a store API key or a plugin token.

Tier-3 tools are confirmation-gated exactly as on the merchant connection: the first call returns a single-use confirmation token (valid for five minutes) describing what will happen, and the tool acts only when called again with it. Handing a store to a client and closing a store are tier 3, so both will sit behind that gate when the dev-store tools ship.

The lifecycle, endpoint by endpoint

The affiliate surface lives under /v1/affiliate and is reachable only with an affiliate connection's token — a merchant token or a plugin token gets 403. The affiliate is always derived from the credential, never from a parameter, so foreign store ids are simply not found.

The active working store

Everything merchant-shaped — products, pages, theme, settings, the whole tier-scoped surface a merchant connection has — runs against the connection's active dev store. A freshly minted affiliate connection has none, so the first thing an assistant does is create a dev store or activate an existing one. Until then every merchant-surface call is refused with 403 and the message "No active dev store selected. Call select_dev_store (POST /v1/affiliate/dev-stores/{id}/activate) first." — the store is never guessed.

Only one store is active per connection. Switching stores is an explicit activate, so an assistant can never edit the wrong client's build by accident.

From an assistant this is select_dev_store, which accepts the store id, the dev-store id, or the exact label, store name or domain from list_dev_stores; clear_dev_store deselects. create_dev_store selects what it creates, so the very next product or page call lands in the new store. Selecting changes nothing inside any store — it only decides which store the other tools reach — which is why both selection tools sit under devstore:read at tier 1.

Handover

transfer emails the client an accept link. While the handover is pending the store's state is transfer_pending and it can still be cancelled. When the client accepts they choose a plan and pay at once — no trial — and in one step the store's dev flag is cleared, its sandbox subscription is ended, and ownership moves to the client. From that moment the affiliate connection can no longer reach it, and the affiliate's commission record begins.

Discovering the tools

As on the merchant connection: call tools/list after connecting rather than hard-coding names. The dev-store tools (list_dev_stores, select_dev_store, clear_dev_store, create_dev_store, transfer_dev_store, cancel_dev_store_transfer, close_dev_store) appear alongside the merchant-surface tools the granted tier allows, and each schema states whether the tool is confirmation-gated: handing over, taking a handover back and closing all ask first, the same in-band way a merchant's live changes do.

What is live, and what gates it

Being explicit, because this surface is early access rather than general availability:

• Live in production: the OAuth routing to the affiliate dashboard, its approval screen (tiers, data terms), the /v1/affiliate endpoints, the ownership checks on every request, and the hosted server's dev-store tools. A freshly minted connection has no working store; list_dev_stores says so, and create_dev_store or select_dev_store fixes it in one call. Until then the merchant-shaped tools answer 403 with the API's own message naming select_dev_store.
• Gate: the account needs an approved affiliate to mint a connection at all, and the affiliate programme needs dev stores enabled by Orbit before create_dev_store will succeed — the API refuses with the programme rule by name (dev stores not enabled, account not yet approved, open dev-store limit reached). The merchant pilot allowlist does not apply to affiliate connections.

This page will drop its banner when dev stores are enabled for every affiliate programme by default.

Reference

• MCP for merchants — the merchant connection, and the tier and confirmation model this page reuses
• MCP for developers — for the assistant that helps you build a plugin
• OAuth scopes — what each merchant-surface scope permits