claude-code - 💡(How to fix) Fix [Bug] Connector marketplace OAuth fails for multi-region SaaS partners with region-specific authorization servers [1 participants]

Bug Description Title: Connector marketplace OAuth registration assumes single hostname — blocks all multi-region SaaS partners (Customer.io EU users currently broken)

Organization ID: 1303f3f0-90c7-41c5-8d68-fd6b10f89a9e

Surface: Claude Desktop — connector marketplace (built-in connector flow, not custom connector)

Reporter: Glen Cornell, Product Manager at Customer.io (enterprise plan)

Connector: Customer.io (recently approved, ~1 week ago via partnership thread with Anthony Bibbs)

Summary

The connector marketplace registers OAuth dynamic client registration against a single hardcoded hostname per connector listing. For SaaS partners with strictly-segregated multi-region architecture, this means users from any non-listed region cannot complete the OAuth handshake and are blocked from connecting. There is no point in the flow where the user can specify their region, and no mechanism in the MCP spec for the server to redirect to a region-specific authorization server.

Specific error

"OAuth client not found" — surfaced when an EU Customer.io user attempts to add the connector through Claude Desktop. The handshake hits mcp.customer.io (US), tries to register a client, fails because the EU user has no workspace on the US instance.

Reproduction steps

1. Have a Customer.io account on the EU region (workspace exists at mcp-eu.customer.io, no corresponding workspace on mcp.customer.io).
2. Open Claude Desktop → Settings → Connectors → add the Customer.io connector from the directory.
3. Begin the OAuth flow.
4. Observe the "OAuth client not found" error after the registration handshake.

100% reproducible with any EU-only Customer.io account.

Expected behavior

Either:

• The marketplace prompts the user for their region before initiating OAuth, OR
• The connector listing supports multiple region-specific OAuth registration URLs, OR
• The OAuth handshake supports HTTP redirects so the server can route the client to the correct regional authorization server.

Actual behavior

OAuth registration is initiated against the single hardcoded US hostname (mcp.customer.io). EU users error out and have no remediation path through the standard connector flow. They can only connect by manually adding a custom connector with the EU URL — which requires Owner-level Claude permissions that most users don't have.

Impact

• All Customer.io EU customers attempting to use the connector through Claude Desktop are blocked. EU is fully unusable through the marketplace today.
• Not Customer.io-specific. This affects every multi-region SaaS partner in the connectors directory whose data residency commitments prevent cross-region routing (HubSpot, ZoomInfo, Atlassian, Notion, etc., all have similar architectures).
• For SaaS with GDPR / data residency commitments, working around this by proxying EU traffic through US is not viable — it violates DPAs and creates Schrems II / CLOUD Act exposure.

Customer.io configuration context

• US MCP server: mcp.customer.io (currently the marketplace listing)
• EU MCP server: mcp-eu.customer.io (data residency, no cross-region routing by design)
• Each MCP server only has visibility into workspaces in its own region.

Workarounds explored / found insufficient

1. Two separate connector listings (US + EU): rejected — sets bad precedent for the marketplace and doesn't generalize across multi-region partners.
2. Proxying EU traffic through US: not viable due to GDPR + customer DPA commitments.
3. managedMcpServers config: partial fix for enterprise customers whose Claude admin can centrally push the EU URL. Doesn't help self-serve users, which are the majority of marketplace traffic.
4. HTTP redirect at the OAuth final-connection step: prototype in flight (Customer.io engineering). Appears to work in Electron-based clients (Claude Desktop, VS Code, Cursor) because they follow redirects via node fetch, but is not in the MCP spec or any RFC and would silently break in native clients (Swift, ObjC, C). Fragile and undocumented.

Requested resolution

Add first-class multi-region support to the connector flow. Most likely candidates:

• A region-selection step in the marketplace UI before OAuth initiation, OR
• A spec addition allowing connectors to declare multiple region-specific OAuth registration URLs, OR
• Officially supporting HTTP redirects in the OAuth handshake so server-side region routing becomes spec-compliant.

We'd love 15 minutes with whoever owns the connector marketplace product / MCP spec roadmap to walk through what we've seen.

Related

• Existing email thread with Anthony Bibbs ([email protected]) about this — Naomi West and Glen Cornell looped in.
• Fin support conversation ID: 215474112452689

Fix / Workaround

Bug Description Title: Connector marketplace OAuth registration assumes single hostname — blocks all multi-region SaaS partners (Customer.io EU users currently broken)

Organization ID: 1303f3f0-90c7-41c5-8d68-fd6b10f89a9e

Surface: Claude Desktop — connector marketplace (built-in connector flow, not custom connector)

Reporter: Glen Cornell, Product Manager at Customer.io (enterprise plan)

Connector: Customer.io (recently approved, ~1 week ago via partnership thread with Anthony Bibbs)

Summary

The connector marketplace registers OAuth dynamic client registration against a single hardcoded hostname per connector listing. For SaaS partners with strictly-segregated multi-region architecture, this means users from any non-listed region cannot complete the OAuth handshake and are blocked from connecting. There is no point in the flow where the user can specify their region, and no mechanism in the MCP spec for the server to redirect to a region-specific authorization server.

Specific error

"OAuth client not found" — surfaced when an EU Customer.io user attempts to add the connector through Claude Desktop. The handshake hits mcp.customer.io (US), tries to register a client, fails because the EU user has no workspace on the US instance.

Reproduction steps

1. Have a Customer.io account on the EU region (workspace exists at mcp-eu.customer.io, no corresponding workspace on mcp.customer.io).
2. Open Claude Desktop → Settings → Connectors → add the Customer.io connector from the directory.
3. Begin the OAuth flow.
4. Observe the "OAuth client not found" error after the registration handshake.

100% reproducible with any EU-only Customer.io account.

Expected behavior

Either:

• The marketplace prompts the user for their region before initiating OAuth, OR
• The connector listing supports multiple region-specific OAuth registration URLs, OR
• The OAuth handshake supports HTTP redirects so the server can route the client to the correct regional authorization server.

Actual behavior

OAuth registration is initiated against the single hardcoded US hostname (mcp.customer.io). EU users error out and have no remediation path through the standard connector flow. They can only connect by manually adding a custom connector with the EU URL — which requires Owner-level Claude permissions that most users don't have.

Impact

• All Customer.io EU customers attempting to use the connector through Claude Desktop are blocked. EU is fully unusable through the marketplace today.
• Not Customer.io-specific. This affects every multi-region SaaS partner in the connectors directory whose data residency commitments prevent cross-region routing (HubSpot, ZoomInfo, Atlassian, Notion, etc., all have similar architectures).
• For SaaS with GDPR / data residency commitments, working around this by proxying EU traffic through US is not viable — it violates DPAs and creates Schrems II / CLOUD Act exposure.

Customer.io configuration context

• US MCP server: mcp.customer.io (currently the marketplace listing)
• EU MCP server: mcp-eu.customer.io (data residency, no cross-region routing by design)
• Each MCP server only has visibility into workspaces in its own region.

Workarounds explored / found insufficient

1. Two separate connector listings (US + EU): rejected — sets bad precedent for the marketplace and doesn't generalize across multi-region partners.
2. Proxying EU traffic through US: not viable due to GDPR + customer DPA commitments.
3. managedMcpServers config: partial fix for enterprise customers whose Claude admin can centrally push the EU URL. Doesn't help self-serve users, which are the majority of marketplace traffic.
4. HTTP redirect at the OAuth final-connection step: prototype in flight (Customer.io engineering). Appears to work in Electron-based clients (Claude Desktop, VS Code, Cursor) because they follow redirects via node fetch, but is not in the MCP spec or any RFC and would silently break in native clients (Swift, ObjC, C). Fragile and undocumented.

Requested resolution

Add first-class multi-region support to the connector flow. Most likely candidates:

• A region-selection step in the marketplace UI before OAuth initiation, OR
• A spec addition allowing connectors to declare multiple region-specific OAuth registration URLs, OR
• Officially supporting HTTP redirects in the OAuth handshake so server-side region routing becomes spec-compliant.

We'd love 15 minutes with whoever owns the connector marketplace product / MCP spec roadmap to walk through what we've seen.

Related

• Existing email thread with Anthony Bibbs ([email protected]) about this — Naomi West and Glen Cornell looped in.
• Fin support conversation ID: 215474112452689