We are integrating the MetaMask Embedded Wallet SDK into our MERN application and need clarification regarding the following application flow.
Our application has two different stages:
1. Login / Registration
Social Login
Email Passwordless
External Wallets such as MetaMask, etc.
2. Existing Platform Login → Connect Wallet
Our platform also supports a separate Email + Password login.
After the user logs in using Email + Password, we have a Connect Wallet button.
When the user clicks Connect Wallet, we need to load the MetaMask SDK and display only the available External Wallets such as MetaMask, WalletConnect, etc.
For both flows, we would like to use the same MetaMask SDK and the same Client ID.
However, when we initialize/load the SDK again after the Email + Password login and try to connect to an External Wallet, we repeatedly receive:
WalletLoginError: Failed to connect with wallet.
Wallet connector is not ready yet.
Please wait for init function to resolve before calling connect/connectTo function
We also tried configuring the available login methods through the MetaMask Developer Dashboard, including hiding Social Login and Email Passwordless. However, those options are then also hidden from the Login / Registration flow, which does not meet our requirement.
Our Questions
Is it officially supported to use the same MetaMask SDK Client ID for both flows and initialize/re-initialize the SDK at different stages of the application?
After an Email + Password login, what is the recommended way to initialize or re-initialize the SDK before calling connect() / connectTo() for External Wallets?
Is there a recommended way to change/filter the available wallet connection methods dynamically based on the current application stage?
*
Registration → Social Login + Email Passwordless + External Wallets
*
After Email + Password login → External Wallets only
Is there any recommended configuration or implementation pattern to avoid the “Wallet connector is not ready yet” error when switching between these two flows?
If the SDK does not support this flow with the same Client ID, what would be the recommended architecture/configuration for implementing this requirement?
We would appreciate guidance on the recommended SDK initialization and wallet connection pattern for this use case.
Short answer: one Embedded Wallets client ID for both entry points is fine. The client ID identifies your Embedded Wallets project and the authentication connections configured for it in the Developer Dashboard (Authentication); it does not need to differ because the user arrived at wallet connection after your own email/password session.
On the error.Wallet connector is not ready yet. Please wait for init function to resolve... is a lifecycle race, not a client ID problem: connect() / connectTo() is being called on an SDK instance whose asynchronous initialization has not resolved. The two patterns that produce it most often are (a) creating the instance and invoking a connector in the same unawaited path, and (b) re-creating the SDK on a route change / remount so the instance that receives connect() is not the one that finished initializing.
Practical guidance:
Create and initialize the SDK once at a stable boundary of your app (for React, the SDK provider at the app root) rather than per screen or per button click.
Keep the initialization state/promise and only enable your Connect Wallet control once it has resolved.
After your platform’s email/password login succeeds, gate the wallet UI in your own application state and reuse the already-initialized instance to start the external-wallet connection.
If you must tear down and re-create the SDK (for example after a full logout), stop using the old instance, await initialization of the new one, and only then call connect() / connectTo().
I’m deliberately not pasting an initialization snippet, because the exact class/hook and init call differ between the React, Vue, and JavaScript SDKs — see the per-framework quick starts and SDK references in embedded-wallets examples and the React SDK docs for the surface that matches your installed package.
On showing different login options per stage. Dashboard authentication and login-screen settings apply to the project/client ID (Authentication, Customization), which is why hiding social/passwordless there also removed them from your registration flow. Dashboard config is not a per-page or per-session switch. Whether your specific SDK version lets you narrow the connectors offered at initialization time (rather than project-wide) depends on the package and version, so tell me which one you’re on and I’ll confirm against that SDK’s options instead of guessing.
To give you version-accurate initialization and connector code, please reply with: (1) the exact Embedded Wallets package name and version from your package.json, (2) whether this is the React integration or a direct JavaScript integration, and (3) the sanitized code that creates/initializes the SDK plus the code path that calls connect() / connectTo(), including where route changes or unmounts happen. Please remove client IDs, secrets, and any credentials before sharing.
If you’d rather continue this with account/project-level context, you can also open a ticket at https://support.metamask.io/join-official-metamask-discord/ — but posting the sanitized details here is the fastest path and keeps the answer useful to other developers.
Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.
In addition to the bot reply, which is explaining everything, here is a short answer for all, if you want to feed your agent for a quick integration.
Yes, there is only one client id from web3auth
You need to initialize once the application loads to activate web3auth in your website
3.Depends if you want to use custom login. If custom login is happening, you can send the id token to web3auth at any stage and the login will be totally invisible for the user. If using standard web3auth logins, you should login first.
Just make sure to init at the first mount to avoid this issue