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

[GH-ISSUE #3686] Organization additional fields not returning new fields #9687

New Issue
Closed
opened 2026-04-13 05:19:11 -05:00 by GiteaMirror · 11 comments
GiteaMirror commented 2026-04-13 05:19:11 -05:00
Owner
Copy Link

Originally created by @senyosimpson on GitHub (Jul 29, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/3686

Originally assigned to: @ping-maxwell on GitHub.

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

To reproduce, just use my configuration down below and try get the field publicId on the data returned by useActiveOrganization or authClient.organization.list()

Current vs. Expected behavior

The expected behaviour is that the field publicId exists on the returned data from the function and that type inference works.

The current behaviour is that neither work.

What version of Better Auth are you using?

1.3.4

Provide environment information

MacOS

Which area(s) are affected? (Select all that apply)

Types, Client

Auth config (if applicable)

export const auth = betterAuth({
  user: {
    additionalFields: {
      publicId: {
        type: "string",
        fieldName: "public_id",
        required: false,
        input: false,
        unique: true,
        returned: true,
      },
    },
  },
  plugins: [
    organization({
      teams: {
        enabled: true,
        allowRemovingAllTeams: false,
      },
      schema: {
        organization: {
          additionalFields: {
            publicId: {
              type: "string",
              fieldName: "public_id",
              required: false,
              input: false,
              unique: true,
              returned: true,
            },
          },
        },
        member: {
          additionalFields: {
            publicId: {
              type: "string",
              fieldName: "public_id",
              required: false,
              input: false,
              unique: true,
              returned: true,
            },
          },
        },
        team: {
          additionalFields: {
            publicId: {
              type: "string",
              fieldName: "public_id",
              required: false,
              input: false,
              unique: true,
              returned: true,
            },
          },
        },
        invitation: {
          additionalFields: {
            publicId: {
              type: "string",
              fieldName: "public_id",
              required: false,
              input: false,
              unique: true,
              returned: true,
            },
          },
        },
      },
    }),
  ],
});

And for the client config

export const authClient = createAuthClient({
  plugins: [
    inferAdditionalFields<typeof auth>(),
    organizationClient({
      teams: {
        enabled: true,
      },
      schema: inferOrgAdditionalFields<typeof auth>(),
    }),
  ],
});

Additional context

I tried the useActiveOrganization function and the authClient.organization.list() function and neither return the publicId. The user additional field does return the publicId. Interestingly, when creating an organization, the field is known. If required is true and I try create an organization without inputting the publicId, I get an error. So some part of it is working.

Additionally, type inference is not working so I get errors saying the field doesn't exist on any of the organization types (e.g orgs, teams, etc)

Originally created by @senyosimpson on GitHub (Jul 29, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/3686 Originally assigned to: @ping-maxwell on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce To reproduce, just use my configuration down below and try get the field `publicId` on the data returned by `useActiveOrganization` or `authClient.organization.list()` ### Current vs. Expected behavior The expected behaviour is that the field `publicId` exists on the returned data from the function _and_ that type inference works. The current behaviour is that neither work. ### What version of Better Auth are you using? 1.3.4 ### Provide environment information ```bash MacOS ``` ### Which area(s) are affected? (Select all that apply) Types, Client ### Auth config (if applicable) ```typescript export const auth = betterAuth({ user: { additionalFields: { publicId: { type: "string", fieldName: "public_id", required: false, input: false, unique: true, returned: true, }, }, }, plugins: [ organization({ teams: { enabled: true, allowRemovingAllTeams: false, }, schema: { organization: { additionalFields: { publicId: { type: "string", fieldName: "public_id", required: false, input: false, unique: true, returned: true, }, }, }, member: { additionalFields: { publicId: { type: "string", fieldName: "public_id", required: false, input: false, unique: true, returned: true, }, }, }, team: { additionalFields: { publicId: { type: "string", fieldName: "public_id", required: false, input: false, unique: true, returned: true, }, }, }, invitation: { additionalFields: { publicId: { type: "string", fieldName: "public_id", required: false, input: false, unique: true, returned: true, }, }, }, }, }), ], }); And for the client config export const authClient = createAuthClient({ plugins: [ inferAdditionalFields<typeof auth>(), organizationClient({ teams: { enabled: true, }, schema: inferOrgAdditionalFields<typeof auth>(), }), ], }); ``` ### Additional context I tried the `useActiveOrganization` function and the `authClient.organization.list()` function and neither return the `publicId`. The user additional field _does_ return the `publicId`. Interestingly, when creating an organization, the field is known. If `required` is `true` and I try create an organization without inputting the `publicId`, I get an error. So some part of it is working. Additionally, type inference is not working so I get errors saying the field doesn't exist on any of the organization types (e.g orgs, teams, etc)
GiteaMirror added the enhancementlocked labels 2026-04-13 05:19:11 -05:00
GiteaMirror commented 2026-04-13 05:19:14 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jul 29, 2025):

Hi @senyosimpson! I'm Dosu and I’m helping the better-auth team.

The issue with organization additionalFields like publicId not being returned or inferred is due to missing support in Better Auth v1.3.4. Full runtime and type inference support for organization, team, member, and invitation additionalFields was added in later versions, specifically after PRs #3447, #3483, #3564, #3612, and #3624 (example, example).

To resolve this, upgrade both your server and client to a version after 2025-07-26. After upgrading:

  • If your client and server are in separate projects, manually duplicate the organization additionalFields schema on both sides and pass it to the client plugin using the schema option (or inferOrgAdditionalFields utility) for type inference to work (details).
  • Ensure your database and adapter are actually storing and returning the custom field (e.g., public_id). The adapter maps public_id to publicId in the output, but if the DB doesn’t return the field, it won’t appear in the API response (details).
  • Any mismatch between client and server schemas will result in missing fields or type errors (details).

After upgrading and syncing schemas, both runtime data and type inference for organization additionalFields like publicId should work as expected.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

<!-- gh-comment-id:3131156554 --> @dosubot[bot] commented on GitHub (Jul 29, 2025): <!-- Greeting --> Hi @senyosimpson! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the better-auth team. <!-- Answer --> The issue with organization additionalFields like `publicId` not being returned or inferred is due to missing support in Better Auth v1.3.4. Full runtime and type inference support for organization, team, member, and invitation additionalFields was added in later versions, specifically after PRs #3447, #3483, #3564, #3612, and #3624 ([example](https://github.com/better-auth/better-auth/pull/3447), [example](https://github.com/better-auth/better-auth/pull/3624)). To resolve this, upgrade both your server and client to a version after 2025-07-26. After upgrading: - If your client and server are in separate projects, manually duplicate the organization additionalFields schema on both sides and pass it to the client plugin using the `schema` option (or `inferOrgAdditionalFields` utility) for type inference to work ([details](https://github.com/better-auth/better-auth/pull/3564)). - Ensure your database and adapter are actually storing and returning the custom field (e.g., `public_id`). The adapter maps `public_id` to `publicId` in the output, but if the DB doesn’t return the field, it won’t appear in the API response ([details](https://github.com/better-auth/better-auth/blob/ed574aa2fbd21c1b9e28d4554993067b159a568b/packages/better-auth/src/adapters/create-adapter/index.ts)). - Any mismatch between client and server schemas will result in missing fields or type errors ([details](https://github.com/better-auth/better-auth/issues/3500)). After upgrading and syncing schemas, both runtime data and type inference for organization additionalFields like `publicId` should work as expected. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/c1df2cd5-98ba-4fba-89be-b872f3bb4463?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c1df2cd5-98ba-4fba-89be-b872f3bb4463?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c1df2cd5-98ba-4fba-89be-b872f3bb4463?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c1df2cd5-98ba-4fba-89be-b872f3bb4463?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c1df2cd5-98ba-4fba-89be-b872f3bb4463?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c1df2cd5-98ba-4fba-89be-b872f3bb4463?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c1df2cd5-98ba-4fba-89be-b872f3bb4463?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3686)
GiteaMirror commented 2026-04-13 05:19:15 -05:00
Author
Owner
Copy Link

@senyosimpson commented on GitHub (Jul 30, 2025):

@dosu the server and client are in the same project so that shouldn't be a concern. And the values exist in the database, see as an example (leaked IDs are fine, it's only local):

postgres=# select * from organizations;
                  id                  | name | slug | logo |       created_at        | metadata |      public_id
--------------------------------------+------+------+------+-------------------------+----------+----------------------
 01984889-952a-7da6-8d25-54d1aa460343 | atx  | atx  |      | 2025-07-26 21:00:32.936 |          | org_gwt0g7b11mxy5qiw

postgres=# select * from teams;
                  id                  | name |           organization_id            |       created_at        |       updated_at        |      public_id
--------------------------------------+------+--------------------------------------+-------------------------+-------------------------+---------------------
 01984889-9536-7495-95ef-9aed56d11e63 | atx  | 01984889-952a-7da6-8d25-54d1aa460343 | 2025-07-26 21:00:32.948 |                         | tm_b5j1lnv90dxqw1i8
 01984889-957d-7469-9f3d-b62214ef6694 | atx  | 01984889-952a-7da6-8d25-54d1aa460343 | 2025-07-26 21:00:33.021 | 2025-07-26 21:00:33.021 | tm_7da8kasfcfz1eg4m
(2 rows)

postgres=# select * from members;
                  id                  |           organization_id            |               user_id                | role  |       created_at        |      public_id
--------------------------------------+--------------------------------------+--------------------------------------+-------+-------------------------+----------------------
 01984889-953f-7908-a438-855070fe9264 | 01984889-952a-7da6-8d25-54d1aa460343 | 01984871-8d76-7e17-bd8f-13f76307628a | owner | 2025-07-26 21:00:32.958 | mem_trakvvw0wthanzdh
<!-- gh-comment-id:3135044145 --> @senyosimpson commented on GitHub (Jul 30, 2025): @dosu the server and client are in the same project so that shouldn't be a concern. And the values exist in the database, see as an example (leaked IDs are fine, it's only local): ``` postgres=# select * from organizations; id | name | slug | logo | created_at | metadata | public_id --------------------------------------+------+------+------+-------------------------+----------+---------------------- 01984889-952a-7da6-8d25-54d1aa460343 | atx | atx | | 2025-07-26 21:00:32.936 | | org_gwt0g7b11mxy5qiw postgres=# select * from teams; id | name | organization_id | created_at | updated_at | public_id --------------------------------------+------+--------------------------------------+-------------------------+-------------------------+--------------------- 01984889-9536-7495-95ef-9aed56d11e63 | atx | 01984889-952a-7da6-8d25-54d1aa460343 | 2025-07-26 21:00:32.948 | | tm_b5j1lnv90dxqw1i8 01984889-957d-7469-9f3d-b62214ef6694 | atx | 01984889-952a-7da6-8d25-54d1aa460343 | 2025-07-26 21:00:33.021 | 2025-07-26 21:00:33.021 | tm_7da8kasfcfz1eg4m (2 rows) postgres=# select * from members; id | organization_id | user_id | role | created_at | public_id --------------------------------------+--------------------------------------+--------------------------------------+-------+-------------------------+---------------------- 01984889-953f-7908-a438-855070fe9264 | 01984889-952a-7da6-8d25-54d1aa460343 | 01984871-8d76-7e17-bd8f-13f76307628a | owner | 2025-07-26 21:00:32.958 | mem_trakvvw0wthanzdh ```
GiteaMirror commented 2026-04-13 05:19:16 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jul 30, 2025):

Thanks for confirming the DB state and monorepo setup. Since your config and DB look correct, here are the most likely causes and next steps:

  • Make sure your client plugin for organizationClient uses the schema option with inferOrgAdditionalFields(), as this is required for both runtime and type inference of additionalFields like publicId. The config should look like:
organizationClient({
  teams: { enabled: true },
  schema: inferOrgAdditionalFields<typeof auth>(),
})

  • If you use a select parameter in your API calls or hooks, ensure publicId is included, or it will be omitted from the response due to how the adapter's transformOutput works (source).

  • Enable debugLogs in your Better Auth adapter config and check the logs for the relevant API call to see if publicId is being processed or omitted.

  • Clear your build cache and restart your dev server to rule out stale config/code.

If you still don't see publicId, please share your exact client plugin config for organizationClient and any relevant logs. This will help pinpoint if it's a config, build, or transformation issue.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

<!-- gh-comment-id:3135063222 --> @dosubot[bot] commented on GitHub (Jul 30, 2025): <!-- Answer --> Thanks for confirming the DB state and monorepo setup. Since your config and DB look correct, here are the most likely causes and next steps: - Make sure your client plugin for organizationClient uses the schema option with inferOrgAdditionalFields<typeof auth>(), as this is required for both runtime and type inference of additionalFields like publicId. The config should look like: ```ts organizationClient({ teams: { enabled: true }, schema: inferOrgAdditionalFields<typeof auth>(), }) ``` - If you use a select parameter in your API calls or hooks, ensure publicId is included, or it will be omitted from the response due to how the adapter's transformOutput works ([source](https://github.com/better-auth/better-auth/blob/4ad0a419d370de69071acf176aeb18163349b728/packages/better-auth/src/adapters/create-adapter/index.ts)). - Enable debugLogs in your Better Auth adapter config and check the logs for the relevant API call to see if publicId is being processed or omitted. - Clear your build cache and restart your dev server to rule out stale config/code. If you still don't see publicId, please share your exact client plugin config for organizationClient and any relevant logs. This will help pinpoint if it's a config, build, or transformation issue. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/d2196c33-9d9c-4679-90fe-8d3f6a95edb9?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/d2196c33-9d9c-4679-90fe-8d3f6a95edb9?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/d2196c33-9d9c-4679-90fe-8d3f6a95edb9?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/d2196c33-9d9c-4679-90fe-8d3f6a95edb9?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/d2196c33-9d9c-4679-90fe-8d3f6a95edb9?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/d2196c33-9d9c-4679-90fe-8d3f6a95edb9?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/d2196c33-9d9c-4679-90fe-8d3f6a95edb9?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/cdda13d9-dd27-4d31-b09a-5d8bec92de21/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3686)
GiteaMirror commented 2026-04-13 05:19:17 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Jul 31, 2025):

I'm working on it

<!-- gh-comment-id:3138346990 --> @ping-maxwell commented on GitHub (Jul 31, 2025): I'm working on it
GiteaMirror commented 2026-04-13 05:19:19 -05:00
Author
Owner
Copy Link

@kylegwalsh commented on GitHub (Aug 27, 2025):

I believe I just ran into this issue as well. It looks like useActiveOrganization is returning the additional field value though, so I believe the types are just missing.

<!-- gh-comment-id:3229954471 --> @kylegwalsh commented on GitHub (Aug 27, 2025): I believe I just ran into this issue as well. It looks like `useActiveOrganization` is returning the additional field value though, so I believe the types are just missing.
GiteaMirror commented 2026-04-13 05:19:20 -05:00
Author
Owner
Copy Link

@fodongkara commented on GitHub (Oct 3, 2025):

Con confirm types are still missing in useActiveOrganization and organizations.list() on version 1.3.25.

<!-- gh-comment-id:3364345466 --> @fodongkara commented on GitHub (Oct 3, 2025): Con confirm types are still missing in `useActiveOrganization` and `organizations.list()` on version `1.3.25`.
GiteaMirror commented 2026-04-13 05:19:21 -05:00
Author
Owner
Copy Link

@senyosimpson commented on GitHub (Oct 6, 2025):

it seems that getFullOrganization doesn't return the additional fields either

<!-- gh-comment-id:3370420045 --> @senyosimpson commented on GitHub (Oct 6, 2025): it seems that `getFullOrganization` doesn't return the additional fields either
GiteaMirror commented 2026-04-13 05:19:22 -05:00
Author
Owner
Copy Link

@LickABrick commented on GitHub (Oct 7, 2025):

I seem to have the same issue. My custom field is not return on signIn/signUp:

    additionalFields: {
      onboardingCompleted: {
        type: "boolean",
        required: false,
        defaultValue: false,
        input: false,
        returned: true,
      },
    },
  },

I am on 1.3.27

<!-- gh-comment-id:3378433175 --> @LickABrick commented on GitHub (Oct 7, 2025): I seem to have the same issue. My custom field is not return on signIn/signUp: ```user: { additionalFields: { onboardingCompleted: { type: "boolean", required: false, defaultValue: false, input: false, returned: true, }, }, }, ``` I am on `1.3.27`
GiteaMirror commented 2026-04-13 05:19:23 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Oct 8, 2025):

Hey guys, the PR is already ready, just waiting on other core maintainers to review my PR and be merged.

<!-- gh-comment-id:3382073956 --> @ping-maxwell commented on GitHub (Oct 8, 2025): Hey guys, the PR is already ready, just waiting on other core maintainers to review my PR and be merged.
GiteaMirror commented 2026-04-13 05:19:24 -05:00
Author
Owner
Copy Link

@KlimentP commented on GitHub (Oct 24, 2025):

@ping-maxwell - thanks for taking of this, any updates on the timeline for this? We are trying to create organizations with custom fields passed to auth.api.createOrganization, but since this doesnt work, we have to create with empty fields and then run the update on the additional fields, and use similarly awkward workarounds for accessing fields of a user's active org

<!-- gh-comment-id:3443242327 --> @KlimentP commented on GitHub (Oct 24, 2025): @ping-maxwell - thanks for taking of this, any updates on the timeline for this? We are trying to create organizations with custom fields passed to auth.api.createOrganization, but since this doesnt work, we have to create with empty fields and then run the update on the additional fields, and use similarly awkward workarounds for accessing fields of a user's active org
GiteaMirror commented 2026-04-13 05:19:25 -05:00
Author
Owner
Copy Link

@ping-maxwell commented on GitHub (Oct 24, 2025):

I'll bring it up to the team.

<!-- gh-comment-id:3444671868 --> @ping-maxwell commented on GitHub (Oct 24, 2025): I'll bring it up to the team.
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#9687
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?