diff --git a/main/docs/customize/custom-domains/multiple-custom-domains/mcd-ea-sdk-bridge.mdx b/main/docs/customize/custom-domains/multiple-custom-domains/mcd-ea-sdk-bridge.mdx
new file mode 100644
index 000000000..1c121d99d
--- /dev/null
+++ b/main/docs/customize/custom-domains/multiple-custom-domains/mcd-ea-sdk-bridge.mdx
@@ -0,0 +1,78 @@
+Note to myself: WE need to also cover authentication-related SDK calls, starting a list:
+
+* initial login redirect
+* token renewal
+* domain-specific logout
+
+
+---
+description: Interim Application Integration Guide
+'og:image': https://cdn2.auth0.com/docs/1.14553.0/img/share-image.png
+'og:title': Interim Application Integration Guide
+'og:url': https://auth0.com/docs/
+permalink: mcd-ea-sdk-bridge
+title: Interim Application Integration Guide
+'twitter:description': Interim Application Integration Guide
+'twitter:title': Interim Application Integration Guide
+---
+<Warning>
+Multiple Custom Domains is currently available in Early Access. To use this feature, you must have an Enterprise plan. By using this feature, you agree to the applicable Free Trial terms in Okta’s [Master Subscription Agreement](https://www.okta.com/legal). To learn more about Auth0's product release cycle, read [Product Release Stages](https://auth0.com/docs/troubleshoot/product-lifecycle/product-release-stages).
+</Warning>
+
+Multiple Custom Domains (MCD) Early Access does not currently support full integration to the Auth0 SDKs. This means that your application cannot rely on the SDKs to automatically select the correct custom domain for authentication redirects. 
+
+During the Early Access phase, you must manually implement logic to determine and apply the correct custom domain to the authentication client configuration.
+
+<Callout>
+This manual process is currently an interim step. We are actively working on updating the Auth0 SDKs to handle the dynamic selection and configuration of custom domains automatically. 
+</Callout>
+
+## Dynamic domain selection for login
+
+To implement multi-branding or white-labeling, your application must read its current context (for example, the URL the user is visiting) and use that information to set the Auth0 `domain` property. 
+
+### Example: JavaScript implementation
+
+This function determines the correct custom domain to use when initializing the authentication client:
+
+```javascript
+
+const DOMAIN_MAP = {
+  'app.alpha-brand.com': 'login.alpha-brand.com',
+  'app.beta-brand.com': 'login.beta-brand.com',
+  // Add other mappings as necessary for your use cases
+};
+
+function getAuthDomain(currentAppHostname) {
+  // 1. Look up the domain based on the current context (hostname)
+  const customDomain = DOMAIN_MAP[currentAppHostname];
+
+  // 2. Return the Custom Domain or fall back to your standard Auth0 domain
+  if (customDomain) {
+    return customDomain;
+  }
+  return 'your-tenant-name.auth0.com'; 
+}
+
+// --- Application Initialization ---
+
+// Get the domain based on the current application's URL
+const authDomain = getAuthDomain(window.location.hostname);
+
+// Configure your Auth SDK/Client manually with the determined domain
+const authClient = new auth0.WebAuth({
+  // 🔑 CRITICAL EA STEP: Use the dynamically selected Custom Domain here
+  domain: authDomain, 
+  clientID: 'YOUR_CLIENT_ID',
+  redirectUri: 'YOUR_CALLBACK_URL',
+  // ... other parameters
+});
+
+// The subsequent call to authClient.authorize() will use the correct MCD URL.
+authClient.authorize();
+
+```
+
+<Note>
+MCD does not require any changes to how your APIs validate access tokens. When a custom domain issues an Access Token, this remains tied to your core Auth0 tenant ID, regardless of which custom domain was used for your flow. 
+</Note>