[GH-ISSUE #2446] API Key owned by Organization #17829

New Issue

GiteaMirror · 2026-04-15T16:10:07-05:00

GiteaMirror commented

2026-04-15 16:10:07 -05:00

Originally created by @anaclumos on GitHub (Apr 26, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/2446

Is this suited for github?

Yes, this is suited for github

Currently, API Keys are tied to Users.

Describe the solution you'd like

There needs to be a way to create an organization-owned API Keys.

Describe alternatives you've considered

I thought of admins of orgs being able to use API Keys of members, or share API keys owned by a user within Org, but seems like an overcomplication. If the owner could be organization, all members authorized within the org would be able to control it.

Additional context

No response

Originally created by @anaclumos on GitHub (Apr 26, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/2446 ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. Currently, API Keys are tied to Users. ### Describe the solution you'd like There needs to be a way to create an organization-owned API Keys. ### Describe alternatives you've considered I thought of admins of orgs being able to use API Keys of members, or share API keys owned by a user within Org, but seems like an overcomplication. If the owner could be organization, all members authorized within the org would be able to control it. ### Additional context _No response_

GiteaMirror added the locked label 2026-04-15 16:10:07 -05:00

GiteaMirror closed this issue

2026-04-15 16:10:08 -05:00

GiteaMirror commented

2026-04-15 16:10:09 -05:00

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

Hi, @anaclumos. I'm Dosu, and I'm helping the better-auth team manage their backlog. I'm marking this issue as stale.

Issue Summary:

Proposal to enable API keys to be owned and managed by organizations.
Aims to streamline access and control for authorized organization members.
Current method of sharing user-owned API keys is too complex for organizations.
No comments or developments have been made on this issue yet.

Next Steps:

Please let me know if this issue is still relevant to the latest version of the better-auth repository by commenting here.
If there is no further input, this issue will be automatically closed in 7 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Jul 26, 2025): Hi, @anaclumos. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog. I'm marking this issue as stale. **Issue Summary:** - Proposal to enable API keys to be owned and managed by organizations. - Aims to streamline access and control for authorized organization members. - Current method of sharing user-owned API keys is too complex for organizations. - No comments or developments have been made on this issue yet. **Next Steps:** - Please let me know if this issue is still relevant to the latest version of the better-auth repository by commenting here. - If there is no further input, this issue will be automatically closed in 7 days. Thank you for your understanding and contribution!

GiteaMirror commented

2026-04-15 16:10:10 -05:00

@FdezRomero commented on GitHub (Jul 26, 2025):

Dosu, this is still an unresolved issue without a good or documented workaround. Please prioritize it in the backlog, thank you.

@FdezRomero commented on GitHub (Jul 26, 2025): Dosu, this is still an unresolved issue without a good or documented workaround. Please prioritize it in the backlog, thank you.

GiteaMirror commented

2026-04-15 16:10:11 -05:00

@chrisvxd commented on GitHub (Aug 23, 2025):

Here's a workaround that worked for me using the server APIs.

First, add organizationId to the schema (I'm using Drizzle)

export const apiKey = pgTable("apikey", {
   // ... default schema
  organizationId: text("organization_id").references(() => organizations.id, {
    onDelete: "cascade",
  }),
});

Then, create a custom endpoint which first calls the createApiKey method, and then updates the row with my organization

export async function POST(request: Request) {
  // Create key
  const data = await auth.api.createApiKey({
    body: {
      name: "project-api-key",
      expiresIn: 60 * 60 * 24 * 7,
      userId: "user-id", // server-only
    },
  });

  // Add organization to row
  const [dbKey] = await db
    .update(apiKeys)
    .set({ organizationId: "organization-id" })
    .where(eq(apiKeys.id, data.id))
    .returning();

  // Provide user with key from `createApiKey`, as key in DB is hashed.
  return NextResponse.json({ ... dbKey, key: data.key });
}

Would be nice to have native support, but this was easy enough.

@chrisvxd commented on GitHub (Aug 23, 2025): Here's a workaround that worked for me using the server APIs. First, add `organizationId` to the schema (I'm using Drizzle) ```ts export const apiKey = pgTable("apikey", { // ... default schema organizationId: text("organization_id").references(() => organizations.id, { onDelete: "cascade", }), }); ``` Then, create a custom endpoint which first calls the `createApiKey` method, and then updates the row with my organization ```ts export async function POST(request: Request) { // Create key const data = await auth.api.createApiKey({ body: { name: "project-api-key", expiresIn: 60 * 60 * 24 * 7, userId: "user-id", // server-only }, }); // Add organization to row const [dbKey] = await db .update(apiKeys) .set({ organizationId: "organization-id" }) .where(eq(apiKeys.id, data.id)) .returning(); // Provide user with key from `createApiKey`, as key in DB is hashed. return NextResponse.json({ ... dbKey, key: data.key }); } ``` Would be nice to have native support, but this was easy enough.

GiteaMirror commented

2026-04-15 16:10:12 -05:00

@whitetown commented on GitHub (Aug 23, 2025):

First, add organizationId to the schema (I'm using Drizzle)

I added to metadata... to avoid possible conflicts in the future
And now I need to add another endpoint to show keys for an organization members.

@whitetown commented on GitHub (Aug 23, 2025): > First, add `organizationId` to the schema (I'm using Drizzle) I added to metadata... to avoid possible conflicts in the future And now I need to add another endpoint to show keys for an organization members.

GiteaMirror commented

2026-04-15 16:10:12 -05:00

@pranavp10 commented on GitHub (Aug 25, 2025):

Thanks @ping-maxwell, I’ve been eagerly waiting for this feature!

@pranavp10 commented on GitHub (Aug 25, 2025): Thanks @ping-maxwell, I’ve been eagerly waiting for this feature!

GiteaMirror commented

2026-04-15 16:10:13 -05:00

@dosubot[bot] commented on GitHub (Nov 24, 2025):

Hi, @anaclumos. I'm Dosu, and I'm helping the better-auth team manage their backlog and am marking this issue as stale.

Issue Summary

You requested a feature to allow API keys to be owned and managed by organizations for easier access control.
The issue has seen some community interest, including workarounds shared by users like chrisvxd involving schema changes and custom endpoints.
FdezRomero highlighted the importance of this feature and requested prioritization.
Despite the interest and discussion, the feature remains unresolved and not yet implemented.

Next Steps

Please let me know if this feature is still relevant to your needs with the latest version of better-auth by commenting on this issue.
If I don’t hear back within 7 days, I will automatically close this issue to keep the backlog manageable.

Thanks for your understanding and contribution!

@dosubot[bot] commented on GitHub (Nov 24, 2025): Hi, @anaclumos. I'm [Dosu](https://dosu.dev), and I'm helping the better-auth team manage their backlog and am marking this issue as stale. **Issue Summary** - You requested a feature to allow API keys to be owned and managed by organizations for easier access control. - The issue has seen some community interest, including workarounds shared by users like chrisvxd involving schema changes and custom endpoints. - FdezRomero highlighted the importance of this feature and requested prioritization. - Despite the interest and discussion, the feature remains unresolved and not yet implemented. **Next Steps** - Please let me know if this feature is still relevant to your needs with the latest version of better-auth by commenting on this issue. - If I don’t hear back within 7 days, I will automatically close this issue to keep the backlog manageable. Thanks for your understanding and contribution!

GiteaMirror commented

2026-04-15 16:10:13 -05:00

@mmailaender commented on GitHub (Nov 25, 2025):

This is still relevant. In the workaround the organization API key is still related to a user. This is not ideal as a user can leave a company. Also adding an own API layer to interact with the API keys adds unnecessary API complexity.

@mmailaender commented on GitHub (Nov 25, 2025): This is still relevant. In the workaround the organization API key is still related to a user. This is not ideal as a user can leave a company. Also adding an own API layer to interact with the API keys adds unnecessary API complexity.

GiteaMirror commented

2026-04-15 16:10:14 -05:00

@thomasvanvelzen commented on GitHub (Dec 5, 2025):

This is definitely still relevant for me as well. In my case, API keys need to outlive individual users and stay tied to the organization itself. Relying on a user-owned key introduces risk (user leaves, permissions change, etc.) and complicates automation. Native org-owned API keys would avoid the extra API layer and keep access control predictable and maintainable. Would really appreciate official support for this.

@thomasvanvelzen commented on GitHub (Dec 5, 2025): This is definitely still relevant for me as well. In my case, API keys need to outlive individual users and stay tied to the organization itself. Relying on a user-owned key introduces risk (user leaves, permissions change, etc.) and complicates automation. Native org-owned API keys would avoid the extra API layer and keep access control predictable and maintainable. Would really appreciate official support for this.

GiteaMirror commented

2026-04-15 16:10:15 -05:00

@giray123 commented on GitHub (Dec 22, 2025):

I am also waiting for the native support for Organization owned API Keys.

@giray123 commented on GitHub (Dec 22, 2025): I am also waiting for the native support for Organization owned API Keys.

GiteaMirror commented

2026-04-15 16:10:16 -05:00

@darklight9811 commented on GitHub (Jan 31, 2026):

Any news on this? Its really weird that we can't handle those natively

@darklight9811 commented on GitHub (Jan 31, 2026): Any news on this? Its really weird that we can't handle those natively

GiteaMirror commented

2026-04-15 16:10:16 -05:00

@hugodemelo commented on GitHub (Feb 1, 2026):

What makes better auth great its also its plugins, this friction between the api keys and organizations plugin is a severe limitation.

API keys scoped to users create a false ownership model for B2B - when an employee leaves, the org loses its integration until someone else generates a new key.

this feature request should be taken seriously.

@hugodemelo commented on GitHub (Feb 1, 2026): What makes better auth great its also its plugins, this friction between the api keys and organizations plugin is a severe limitation. API keys scoped to users create a false ownership model for B2B - when an employee leaves, the org loses its integration until someone else generates a new key. this feature request should be taken seriously.

GiteaMirror commented

2026-04-15 16:10:17 -05:00

@thomasmol commented on GitHub (Feb 1, 2026):

Created a pr here for allowing additionalFields in the api-key plugin schema: https://github.com/better-auth/better-auth/pull/7744

This could already some use-cases for organization based api-keys, although not all

@thomasmol commented on GitHub (Feb 1, 2026): Created a pr here for allowing `additionalFields` in the `api-key` plugin schema: https://github.com/better-auth/better-auth/pull/7744 This could already some use-cases for organization based api-keys, although not all

GiteaMirror commented

2026-04-15 16:10:17 -05:00

@heiwen commented on GitHub (Feb 2, 2026):

+1 on this, looking for the same functionality right now.

Seems this is the #1 upvoted issue for better-auth.

@ping-maxwell @bytaesu @himself65 what do you guys think, anything we can help with?

@heiwen commented on GitHub (Feb 2, 2026): +1 on this, looking for the same functionality right now. Seems this is the #1 upvoted issue for better-auth. @ping-maxwell @bytaesu @himself65 what do you guys think, anything we can help with?

GiteaMirror commented

2026-04-15 16:10:18 -05:00

@Ciantic commented on GitHub (Feb 11, 2026):

Current API Key implementation is heavily user specific, maybe I would even call current implementation "User API keys" like Personal Access Tokens in other systems.

Every user can create API keys, there is no permissions check like "create" or "delete" for API keys
Every user can add any permissions to API keys, they are effectively just strings to it

So if you just add manual association to organization, you have to also add ability to filter what permissions per organization is given. Then there is future compatiblity, if your hack works, will it work in next version? These are PATs not organization API Keys.

I think there could be another plugin like organizationApiKeys, and this ApiKeys implementation is restricted for PATs.

(Why this matters? Because PATs (what API keys now are) are different concept from API keys in my opinion. Best would be to rename API Keys to -> Personal Access Tokens, but that is probably not possible anymore.)

@Ciantic commented on GitHub (Feb 11, 2026): Current API Key implementation is heavily user specific, maybe I would even call current implementation "User API keys" like Personal Access Tokens in other systems. - Every user can create API keys, there is no permissions check like "create" or "delete" for API keys - Every user can add *any* permissions to API keys, they are effectively just strings to it So if you just add manual association to organization, you have to also add ability to filter what permissions per organization is given. Then there is future compatiblity, if your hack works, will it work in next version? These are PATs not organization API Keys. I think there could be another plugin like organizationApiKeys, and this ApiKeys implementation is restricted for PATs. (Why this matters? Because PATs (what API keys now are) are different concept from API keys in my opinion. Best would be to rename API Keys to -> Personal Access Tokens, but that is probably not possible anymore.)

GiteaMirror commented

2026-04-15 16:10:19 -05:00

@Daspy11 commented on GitHub (Feb 16, 2026):

Having heard so many good things about better auth, I came here and am /baffled/ at the scope of the project while leaving this out. WTF. Not to shit on good honest work from maintainers here, but how did sign in with ethereum end up on the roadmap before org-scoped API keys?

@Daspy11 commented on GitHub (Feb 16, 2026): Having heard so many good things about better auth, I came here and am /baffled/ at the scope of the project while leaving this out. WTF. Not to shit on good honest work from maintainers here, but how did sign in with ethereum end up on the roadmap before org-scoped API keys?

GiteaMirror commented

2026-04-15 16:10:19 -05:00

@Bekacru commented on GitHub (Feb 16, 2026):

I’d argue that Sign in with Ethereum is more of a priority for an auth framework than API keys. API keys for the most part, can be implemented without needing your auth library to do anything.

That said, we already built a solution for API keys when we first introduced the plugin, using a reference pattern similar to what we did with the Stripe plugin. Our original idea was to avoid making assumptions across plugins and to keep everything fully isolated. For example, if you had your own custom organization implementation, you should still be able to use the API key plugin independently of it

However, based on user demand and how quickly the plugin system was adopted, we’re gradually moving toward tighter integration between certain plugins. We started with the Stripe plugin, and the API key improvements are on the roadmap for the 1.5 release.

@Bekacru commented on GitHub (Feb 16, 2026): I’d argue that Sign in with Ethereum is more of a priority for an auth framework than API keys. API keys for the most part, can be implemented without needing your auth library to do anything. That said, we already built a solution for API keys when we first introduced the plugin, using a reference pattern similar to what we did with the Stripe plugin. Our original idea was to avoid making assumptions across plugins and to keep everything fully isolated. For example, if you had your own custom organization implementation, you should still be able to use the API key plugin independently of it However, based on user demand and how quickly the plugin system was adopted, we’re gradually moving toward tighter integration between certain plugins. We started with the Stripe plugin, and the API key improvements are on the roadmap for the 1.5 release.

GiteaMirror commented

2026-04-15 16:10:20 -05:00

@darklight9811 commented on GitHub (Feb 17, 2026):

@Bekacru maybe this could be an opportunity to document a proper way to do inter-plugin communication for more advanced use cases

@darklight9811 commented on GitHub (Feb 17, 2026): @Bekacru maybe this could be an opportunity to document a proper way to do inter-plugin communication for more advanced use cases

GiteaMirror commented

2026-04-15 16:10:20 -05:00

@Censacrof commented on GitHub (Feb 18, 2026):

+1 we need this for our SaaS. Our current work-around involved creating a dummy user tied to only one organization each time we need to generate a new api key. It works, but it could be better.

@Censacrof commented on GitHub (Feb 18, 2026): +1 we need this for our SaaS. Our current work-around involved creating a dummy user tied to only one organization each time we need to generate a new api key. It works, but it could be better.

GiteaMirror commented

2026-04-15 16:10:20 -05:00

@ping-maxwell commented on GitHub (Feb 19, 2026):

Hey guys, sorry for the delayed updates.
This is being actively worked on. It will be part of the next release.

@ping-maxwell commented on GitHub (Feb 19, 2026): Hey guys, sorry for the delayed updates. This is being actively worked on. It will be part of the next release.

Sign in to join this conversation.

Branches Tags

2026-05-22/chore/adopt-agents-md

2026-05-22/refactor/string-case-utils

dependabot/npm_and_yarn/uuid-14.0.0

dependabot/npm_and_yarn/turbo-2.9.14

changeset-release/main

main

2026-05-14/fix/passkey-verify-error-and-claim

dependabot/npm_and_yarn/samlify-2.13.0

dependabot/npm_and_yarn/ws-8.20.1

changeset-release/next

dependabot/npm_and_yarn/demo/electron/demo-minor-patch-519ef7475f

dependabot/github_actions/github-actions-98f3470200

client-assertions-main

2026-05-15/ci/fix-sqlite-abi-mismatch

2026-05-15/fix/organization-team-add-cascade

2026-05-15/fix/parse-set-cookie-value-validation

2026-05-13/feat/captcha-wildcard-endpoints

2026-05-13/ci/stabilize-docker-startup

fix/i18n-before-hook-translation

fix/disable-migration-generate

2026-05-07/fix/admin-set-password-upsert

2026-05-10/fix/cookie-drain-order

2026-05-10/feat/hooks-finally

2026-05-09/fix/cookie-drain-order

2026-05-09/feat/hooks-finally

2026-05-08/feat/register-before-send

fix/stripe/subscription-data-merge

2026-05-01/chore/pnpm-v11-harden

chore/pnpm-v11

2026-04-29/feat/google-include-granted-scopes

2026-04-29/fix/oauth-account-scope-semantics

2026-04-27/fix/nextcookies-idempotent-writes

2026-04-26/fix/harden-proxy-host-validation

2026-04-26/refactor/stripe-callback-signature-cleanup

2026-04-26/fix/stripe-subscription-callback-timing

2026-04-11/fix/sveltekit-app-modules

feat/open-api-zod-contract

feat/oauth-provider-backchannel-logout-next

feat/oauth-idp-initiated-bounce

refactor/sign-in-challenges

2026-04-21/fix/oauth-rfc-input-validation

fix/release-notes-new-packages

fix/two-factor-identity-guard

fix/resource

feat/emailpassword-authorize

2026-04-12/security/dynamic-baseurl-proxy-trust-default

feat/oauth-provider-at-hash-v2

fix/release-grep-fallback

claude/address-review-comments-JhFLr

claude/slack-update-stripe-docs-consistency-8Sc0w

feat/async-auth

fix/two-factor-totp-verified-enrollment

feat/plugin-ui

codex/blog-1-6-release-post

2026-04-06/fix/type-any-guards

2026-04-05/chore/downgrade-better-call

2026-04-04/ci/skip-vercel-fork-prs

2026-03-28/ci/add-autofix-ci

chore/release-preview-script

himself65/2026/02/19/role

2026-03-24/fix/update-user-info-on-link

2026-03-20/docs/improve-website

2026-03-20/fix/anonymous-onlinkaccount-expo

2026-02-17/fix/anonymous-link-state

fix/8607-saml-inresponseto

fix/8549-scim-patch-noop

v1.4.x

refactor/migration-snapshot-tests

worktree-magic-link-additional-data

chore/migrate-build-to-rollup

worktree-fix-dynamic-baseurl-8447

2026-03-06/chore/public-api-check

fix/close-8156-regression-test

fix/secondary-storage-json-error-handling

himself65/verification-namespace

cursor/issue-8307-validation-79a3

himself65/2026/01/30/error-mdx

v1.4.x-staging

fix/email-otp-user

fix/restrict-full-organization-access-roles

himself65/2026/02/12/count

himself65/2026/02/04/define-plugin

2026-02-04/feat/add-pluralize

cursor/better-auth-js-integration-ec21

cursor/expo-state-mismatch-394c

2026-02-01/fix/org-update-role-sync-members

cursor/issue-7607-investigation-e146

cursor/email-generation-helper-0ff6

himself65/2026/01/21/avoid-spread-operator

himself65/2026/01/14/cli

claude/slack-add-docs-pr-NMvgO

claude/slack-add-advanced-useplural-WHKYL

feat/hooks-pos

feat/2fa-phone

feat/2fa

fix/rotation

fix/username-check

v1.3.x

refactor/organization

feat/multiple-client-ids-social-providers

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/better-auth#17829