Thanks Ritik — sorry you’re hitting this. I dug through your report and pulled out the key details so the support team can triage quickly, plus a few targeted checks and a likely culprit.
Summary of what you shared
- Reporter: Ritik Joshi
- SDK / Integration: MetaMask Embedded Wallets (using Web3Auth via @web3auth/modal)
- @web3auth/modal version: 10.3.0
- Platform: Next.js (14.2.33 & 16.0.1 tested), React 18.2.0
- Error seen in modal: Something went wrong, error code: E002
- Console/network: POST https://api.web3auth.io/passwordless-service/api/v3/auth/passwordless/start → 400 Bad Request
- Code snippet (modal connectors/loginMethods) provided
- You created Google and Email Passwordless auth connections and a Group Connection in the Web3Auth dashboard; Google works but email_passwordless returns E002 (400)
What I suspect (quick pointers)
- The 400 from the passwordless start endpoint usually means the request body or provider configuration is incorrect or missing required fields. Common causes:
- The Email Passwordless auth connection in the Web3Auth Dashboard is not fully configured (e.g., provider/template/allowed origins not set or verified).
- The modal is sending an unexpected payload because of an incorrect config key in your loginMethods object. In your snippet I noticed you included authConnection: “email_passwordless” inside email_passwordless — that property looks suspicious (I don’t see that used in typical Web3Auth loginMethods config) and could be altering the request payload.
- Grouped connections behaviour: if the group or child auth connection requires additional server-side config or secrets (some providers do), you may need to verify those values on the dashboard.
Immediate action steps to try (fast checks)
- Remove the extra authConnection property from your email_passwordless entry and test again. Example: keep only name, authConnectionId, and groupedAuthConnectionId (as you do for google). That extra key may be producing an invalid request body.
- Confirm the Email Passwordless auth connection in the Web3Auth dashboard is active and fully configured (provider, from address/template, any required API keys/secrets). Make sure any allowed origins/redirect URLs include your app origin.
- Test the email passwordless connection on its own (no grouping) — can you start a passwordless login if you only configure email_passwordless in modal? You said commenting out groupedAuthConnectionId didn’t help, but can you try removing Google entirely and only use email_passwordless? This isolates group vs provider problems.
- Inspect the failing network request body (DevTools → Network → passwordless/start). Copy the request payload (JSON). The 400 response plus request body will show what parameter is malformed or missing.
What I need from you (only if you’re comfortable sharing) — these will let support reproduce/fix quickly
- The full Web3Auth initialization snippet (where you create Web3Auth / Web3AuthModal and call login). The connectors/loginMethods snippet is great, but the rest of init can matter.
- The network request payload for the POST to /passwordless/start (Request body) or a screenshot of the Network tab showing request and response JSON. That will pinpoint the missing/invalid field.
- Confirmation that the email passwordless auth connection in the Web3Auth dashboard shows as ACTIVE and any provider settings (you can redact secrets).
Useful references
- Web3Auth Passwordless docs (for configuration checklist): 404 Page Not Found | Documentation | Web3Auth
- Web3Auth modal docs (loginMethods): 404 Page Not Found | Documentation | Web3Auth
If you prefer, paste the network request body here (or a screenshot). If removing the stray authConnection field fixes it, let me know and I’ll mark that as the likely root cause — if not, share the request body and I’ll point the exact missing field to the support engineers.
Thanks — you’ve given a very complete report already. If you want, I can prepare a short repro checklist for the support team after you share the network payload or the full init snippet.
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.
Additionally, we would recommend you to join our biweekly Office Hours to get this resolved even faster. MetaMask Developer Office Hours