Why getSession (and customSession) don't include additionalFields?
@Better Auth
I dived deep into additionalFields, customSession and related concepts. This isn't about using infers for types, that works well for both server and client side.
It seems like even though adding additionalFields, even with returned: true (which is documented as: If the value should be returned on a response body.) it isn't returned to the client when the client calls getSession...
So I found here and there that additionalFields is only for the server side (then what is the returned field for??) and they are all stripped from getSession to client for "safety reasons".. It seems like an unnecessary limitation to me.. (Ping answered here but this isn't clearly documented anywhere else https://www.answeroverflow.com/m/1374165269303263244)
Okay, then I go for customSession and I nuke the config a bit fine, then I see that the customSession already provides the user and the session from params, but still without the additional fields 😅 🥲
Whyyy. Why do I have to make two DB queries where the whole point of this additionalFields would be to avoid extra steps and roundtrips and neatly include the fields.. it already works for the server side why would you strip them away, and even in customSession? Then would it make a LOT more sense for customSession to not do any DB call and let us do that too?
I don't get this I feel like this should at least be easily configurable, like say with that returned field in additionalFields which I still don't know what is for.
I'am on latest. Or should I not experience this? If so I can raise a bug.
AdditionalFields not working as expected, Drizzle - Better Auth
So I'm at my wit's ends, having scoured the web for a similar issue and having tried every config combination imaginable. It's not clear from the docs what is exactly expected to work "out of the box", so I'm hoping I can get more direction here.
What I'm trying to do: Simply extend the user object with a field.
```export const auth = betterAut...
16 Replies
Hey there! I understand your frustration—the interplay between additionalFields, the returned flag, and the customSession plugin can be a bit confusing.
By design, the additionalFields configuration (with the returned: true option) is primarily meant to affect what’s exposed on the server side and in certain API responses (like through sign-in or sign-up endpoints) [5]. However, for security reasons the default behavior when using getSession (or customSession) is to strip these extra fields from the client response. This means that even if you set returned: true, the fields may not make it to the client by default.
When you use customSession, it gets populated from the standard session data. That data is based on what’s stored in the database and then returned via the API—but additionalFields aren’t merged automatically into that response. In other words, the customSession callback gives you the basic user and session objects, and the extended user properties aren’t included unless you explicitly add them there (by doing your own fetch/merge) [4].
I know it can be annoying to have to perform an extra DB query to retrieve those fields when you’d expect them to be there. The idea behind it is to minimize exposing sensitive or unintended data to the client by default. That said, we realize it might be viewed as an unnecessary limitation in some use cases, and we’re looking into making this behavior more configurable.
If you believe this isn’t what you should be experiencing, it would be great to raise a bug report so we can look into it further. We're always trying to ensure the balance between security and ease-of-use while keeping the developer experience smooth [1],
GitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
[4].
Let me know if you have any more questions or need further clarification!
Sources:
5. TypeScript | Better Auth
4. Session Management | Better Auth
1. Types of additionalFields not inferred correctly when customSession plugin is used
TypeScript | Better Auth
Better Auth TypeScript integration.
Session Management | Better Auth
Better Auth session management.
GitHub
Types of additionalFields not inferred correctly when customSession...
Is this suited for github? Yes, this is suited for github To Reproduce Configure an auth instance with some additionalFields and the plugin customSession. Current vs. Expected behavior The types of...
@Better Auth So there's no way to include additional fields even in callback of customSession?
Currently, when using the customSession plugin, additional fields are indeed available at runtime, but they are not automatically inferred in the callback's TypeScript types. This is a known limitation—your custom fields (like those defined in additionalFields) won’t show up in the inferred types inside the customSession callback by default [1].
As a workaround, you can pass your auth options into the customSession plugin. Doing so can help with inferring the custom fields correctly, although it requires some manual setup in your code [4].
Let me know if you have more questions about this or need further assistance!
Sources:
1. Types of additionalFields not inferred correctly when customSession plugin is used
4. Session Management | Better Auth
GitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
Types of additionalFields not inferred correctly when customSession...
Is this suited for github? Yes, this is suited for github To Reproduce Configure an auth instance with some additionalFields and the plugin customSession. Current vs. Expected behavior The types of...
Session Management | Better Auth
Better Auth session management.
@Better Auth So there's no way to include additional fields even in callback of customSession?
Currently, there is a known limitation with the customSession callback where the additional fields you define (via user.additionalFields or session.additionalFields) aren’t automatically inferred in the callback’s TypeScript types—even though they exist at runtime [1]. As a workaround, the documentation suggests pulling your auth configuration options and passing them to the customSession plugin to help with type inference [4]. This way, you can ensure that custom fields are recognized in the callback’s types even though the default behavior doesn’t include them automatically.
Sources:
1. Types of additionalFields not inferred correctly when customSession plugin is used
4. Session Management | Better Auth
GitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
Types of additionalFields not inferred correctly when customSession...
Is this suited for github? Yes, this is suited for github To Reproduce Configure an auth instance with some additionalFields and the plugin customSession. Current vs. Expected behavior The types of...
Session Management | Better Auth
Better Auth session management.
@Better Auth
I'm doing this:
in the options object
Then using that object:
And the type of user indeed has isAdmin but the runtime doesn't....?
@Ping Sorry for pinging, but I feel like this really should be considered a bug not a limitation here.
This sounds like a case of a known issue with the current behavior of the customSession plugin. Although your TypeScript types correctly indicate that the user has the isAdmin field (and similar issues have been reported [1], [4]), the runtime object may not include the additional field when using the plugin with the options object. In other words, the field is defined and correctly typed, but its value is not being passed through at runtime, which many have noted and which is currently being tracked.
A common workaround is to explicitly spread or include the field in your custom session callback if needed. We'll be following up on this issue for a fix in a future release. Thanks for bringing it up, and feel free to track similar GitHub issues or updates on this matter [1], [4].
Sources:
1. Types of additionalFields not inferred correctly when customSession plugin is used
4.
customSession plugin does not infer additionalFields in session typingGitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
Types of additionalFields not inferred correctly when customSession...
Is this suited for github? Yes, this is suited for github To Reproduce Configure an auth instance with some additionalFields and the plugin customSession. Current vs. Expected behavior The types of...
GitHub
customSession plugin does not infer additionalFields in session...Is this suited for github? Yes, this is suited for github To Reproduce import { betterAuth } from "better-auth"; export const auth = betterAuth({ session: { additionalFields: { activeAcco...
@Better Auth
So absolutely the only way to include the additionalFields in the session response that goes to the client is by making another explicit db request in customSession??
I think this should be documented because this isn't clear and actually contrary to what the typing indicates...
Hello! Currently, that's essentially the case. In Better Auth, the session object supplied to the customSession callback doesn’t automatically include the additional fields defined in your configuration. This means that if you want those additionalFields to be sent to the client, you'll need to explicitly fetch or merge that data (for example, making an extra DB request) within your customSession callback [1], [4].
We understand that the typing might suggest otherwise, and it's a point that could use clearer documentation. We're aware of this limitation and are looking into ways to improve both the behavior and the docs for future releases [1], [2].
Sources:
1.
customSession plugin does not infer additionalFields in session typing
4. Session Management | Better Auth
2. Types of additionalFields not inferred correctly when customSession plugin is used GitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
customSession plugin does not infer additionalFields in session...Is this suited for github? Yes, this is suited for github To Reproduce import { betterAuth } from "better-auth"; export const auth = betterAuth({ session: { additionalFields: { activeAcco...
Session Management | Better Auth
Better Auth session management.
@Better Auth Wait, there's definitely an issue... even the auth.api.getSession({ headers: opts.headers }); on server side doesn't include the additionalField??
Hey there! This issue with additional fields not showing up on the server side when calling auth.api.getSession (even when passing headers) is a known challenge—especially when using the customSession plugin. For example, one GitHub issue noted that while the additional field values are correctly returned at runtime, their types (and even their presence in some type checks) might not always be inferred as expected [1]. Additionally, similar concerns have been raised where custom fields like activeAccountId aren’t recognized by TypeScript in the customSession callback, even though they're there at runtime [2].
If you're noticing that the additional field isn’t present at runtime (and not just a type inference problem), here are a few things you might check:
- Ensure that your auth configuration properly defines the additional field with the correct options (and that you’re using
returned: true where needed) [1].
- Confirm that the plugin order is set correctly so that customSession can enhance the session object with those fields.
- Consider updating to the latest Better Auth version if you haven’t already, as many improvements have been added around this area [2].
Feel free to share more details or configuration snippets if you need further help troubleshooting!
Sources:
1. Types of additionalFields not inferred correctly when customSession plugin is used
2. Additional field not included in responseGitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
Types of additionalFields not inferred correctly when customSession...
Is this suited for github? Yes, this is suited for github To Reproduce Configure an auth instance with some additionalFields and the plugin customSession. Current vs. Expected behavior The types of...
GitHub
Additional field not included in response · Issue #2968 · better-...
Bug Description When using Better Auth with additional user fields, the role field is not being included in the user object returned by the signin endpoint, despite being properly configured in the...
@Better Auth
So should getSession (either server or client api) include additionalFields (without customSession for this case)??
user: {
modelName: "users",
additionalFields: {
isAdmin: {
type: "boolean",
fieldName: "is_admin",
required: false,
defaultValue: false,
input: false, // Don't allow users to set this during signup
returned: true,
},
},
},
No customSession in this example.
Yes, if you configure an additional field with returned: true (as in your example with isAdmin), both the server and client versions of getSession will include that field in the user object. The additionalFields are automatically merged into the user (and session) data when the field is marked as returned, regardless of the customSession plugin [9][4].
Sources:
9. TypeScript | Better Auth
4. Database | Better Auth
TypeScript | Better Auth
Better Auth TypeScript integration.
Database | Better Auth
Learn how to use a database with Better Auth.
@Better Auth
But it isn't.. what could be the issue?
It sounds like the error might be coming from a mismatch between your expected routes and the actual configuration – for example, if your baseURL or basePath settings don’t line up, Better Auth can’t match the incoming request to any defined endpoint, which often results in errors like Error 4816 or NOT_FOUND [1], [9].
Double-check that:
- Your Better Auth configuration uses the correct basePath (and, if applicable, baseURL) according to your deployment setup.
- Routes and endpoints are properly defined and not inadvertently skipped (for instance, endpoints marked as SERVER_ONLY might be bypassed).
- You’re following the startup and integration guides exactly, since even a small deviation might cause the router to miss the endpoints [1].
If everything seems configured correctly, you might also want to verify that your migration and initialization steps (such as running "bun better-auth-migrate" or the equivalent for your setup) completed successfully.
Let me know if this helps or if you have more details about your configuration!
Sources:
1. Better Auth + 🦊 Elysia fails with "[Better Auth]: Error 4816"
9. better-auth works with the wrong baseURL
GitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
better-auth/better-auth
The most comprehensive authentication framework for TypeScript - better-auth/better-auth
GitHub
Better Auth + 🦊 Elysia fails with "[Better Auth]: Error 4816" ·...
Is this suited for github? Yes, this is suited for github To Reproduce Hi 🙂! I followed the startup guides for using Better Auth with Elysia, here and here, but I get an "Error 4816" on a...
GitHub
better-auth works with the wrong baseURL · Issue #3215 · better-a...
Is this suited for github? Yes, this is suited for github To Reproduce I have an express backend served under the https://app.mydomain.org/api/ route that runs better-auth. I configure this with th...