github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-24 08:01:56 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #7868] Email OTP plugin missing name field in signIn method (inconsistent with Magic Link) #19565

New Issue
Closed
opened 2026-04-15 18:49:10 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-15 18:49:10 -05:00
Owner
Copy Link

Originally created by @issam-seghir on GitHub (Feb 8, 2026).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/7868

Description

There is an inconsistency between the Email OTP and Magic Link plugins regarding the ability to set a user's name during sign-up.

Magic Link plugin allows passing a name parameter during sign-in:

await signIn.magicLink({
    email: email.toLowerCase(),
    name: email.split("@")[0], // ✅ Supported
    // ... other options
});

Email OTP plugin does NOT support the name parameter:

await signIn.emailOtp({
    email,
    otp,
    name: username, // ❌ Not supported
});

Problem

When users sign up via Email OTP, there is no way to set their initial name/username. This means:

  1. The user's name field remains null in the database
  2. UX is degraded as we can't display a proper username until the user manually updates their profile
  3. Inconsistency with the Magic Link plugin creates confusion

Expected Behavior

The signIn.emailOtp method should accept an optional name parameter (similar to Magic Link) to allow setting a default username during sign-up, especially for new users.

await signIn.emailOtp({
    email,
    otp,
    name: email.split("@")[0], // Should be supported
});

Use Case

In passwordless authentication flows, it's common to extract the username from the email address (part before @) as a default display name. This provides a better initial user experience compared to having no name at all.

Suggested Solution

Add the optional name parameter to the Email OTP sign-in method, matching the API design of the Magic Link plugin for consistency.

Documentation References

Environment

  • Better Auth version: Latest
  • Authentication method: Email OTP (passwordless)
Originally created by @issam-seghir on GitHub (Feb 8, 2026). Original GitHub issue: https://github.com/better-auth/better-auth/issues/7868 ## Description There is an inconsistency between the Email OTP and Magic Link plugins regarding the ability to set a user's name during sign-up. **Magic Link plugin** allows passing a `name` parameter during sign-in: ```typescript await signIn.magicLink({ email: email.toLowerCase(), name: email.split("@")[0], // ✅ Supported // ... other options }); ``` **Email OTP plugin** does NOT support the `name` parameter: ```typescript await signIn.emailOtp({ email, otp, name: username, // ❌ Not supported }); ``` ## Problem When users sign up via Email OTP, there is no way to set their initial name/username. This means: 1. The user's `name` field remains `null` in the database 2. UX is degraded as we can't display a proper username until the user manually updates their profile 3. Inconsistency with the Magic Link plugin creates confusion ## Expected Behavior The `signIn.emailOtp` method should accept an optional `name` parameter (similar to Magic Link) to allow setting a default username during sign-up, especially for new users. ```typescript await signIn.emailOtp({ email, otp, name: email.split("@")[0], // Should be supported }); ``` ## Use Case In passwordless authentication flows, it's common to extract the username from the email address (part before `@`) as a default display name. This provides a better initial user experience compared to having no name at all. ## Suggested Solution Add the optional `name` parameter to the Email OTP sign-in method, matching the API design of the Magic Link plugin for consistency. ## Documentation References - [Email OTP Plugin](https://www.better-auth.com/docs/plugins/email-otp) - [Magic Link Plugin](https://www.better-auth.com/docs/plugins/magic-link) (has `name` field) ## Environment - Better Auth version: Latest - Authentication method: Email OTP (passwordless)
GiteaMirror added the lockedenhancement labels 2026-04-15 18:49:10 -05:00
GiteaMirror commented 2026-04-15 18:49:13 -05:00
Author
Owner
Copy Link

@better-auth-agent[bot] commented on GitHub (Feb 8, 2026):

It looks like you've identified a valid inconsistency between the Email OTP and Magic Link plugins regarding the handling of the name field during sign-in. Specifically, the Email OTP plugin does not currently support this field, whereas the Magic Link plugin does, which can lead to user experience issues when signing up.

Currently, there is an open issue requesting that the signIn.emailOtp method be updated to accept a name parameter. This would allow for a consistent experience across both plugins and would improve the user experience by automatically assigning a username during sign-up, effectively addressing the issues you've mentioned, such as a null name in the database [1].

For your next steps, you could consider:

  1. Tagging @better-auth-agent for further discussion on the inconsistency.
  2. Keeping an eye on updates regarding this issue, as the Better Auth team may implement your suggestions in the future.

What do you think about the idea of having a name parameter added to the Email OTP plugin? Do you think it would improve the user sign-up experience significantly?

If you need more help, tag @better-auth-agent in a comment so I can respond.

Diagram • Discord • GitHub

Diagram Join Star

<!-- gh-comment-id:3868569656 --> @better-auth-agent[bot] commented on GitHub (Feb 8, 2026): It looks like you've identified a valid inconsistency between the Email OTP and Magic Link plugins regarding the handling of the `name` field during sign-in. Specifically, the Email OTP plugin does not currently support this field, whereas the Magic Link plugin does, which can lead to user experience issues when signing up. Currently, there is an open issue requesting that the `signIn.emailOtp` method be updated to accept a `name` parameter. This would allow for a consistent experience across both plugins and would improve the user experience by automatically assigning a username during sign-up, effectively addressing the issues you've mentioned, such as a `null` name in the database [[1]](https://www.better-auth.com/docs/plugins/email-otp). For your next steps, you could consider: 1. Tagging @better-auth-agent for further discussion on the inconsistency. 2. Keeping an eye on updates regarding this issue, as the Better Auth team may implement your suggestions in the future. What do you think about the idea of having a `name` parameter added to the Email OTP plugin? Do you think it would improve the user sign-up experience significantly? _If you need more help, tag @better-auth-agent in a comment so I can respond._ <!-- bot:webhook reply v1 --> [Diagram](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) • [Discord](https://discord.gg/better-auth) • [GitHub](https://github.com/better-auth/better-auth) [![Diagram](https://img.shields.io/badge/Diagram-2b3137?style=flat-square)](https://repodiagrams.s3.eu-north-1.amazonaws.com/better-auth_ultra_detailed_interactive.html) [![Join](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&style=flat-square)](https://discord.gg/better-auth) [![Star](https://img.shields.io/badge/star-181717?logo=github&logoColor=white&style=flat-square)](https://github.com/better-auth/better-auth)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label enhancement locked
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#19565
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?