Scope of api keys
Hey Team,
I'm reaching out to gain a better understanding of the rationale behind implementing API keys at the project level rather than at the application level. Could you share some insights into the decision-making process for this approach?
9 Replies
Hi @Lukas, can you explain application-level?
Users have access to multiple projects and share them with each other in Langfuse. There is no Team/Organization level yet which groups multiple users and projects (n:m)
With multiple projects in Langfuse, currently the scope of the api keys to projects helps route events to the right project while decoupling keys from users (as often multiple use the same project and configure their application together)
For my personal use cases, it would be much easier to have a single api key for all my projects. Routing the events to the right project could be done like in langsmith via a project name parameter
Got it, that would relate api keys to users (or probably better teams/orgs) instead of projects and allow for project selection via a parameter
exactly
This is a great suggestion once there is support for teams/orgs, I probably would not prioritize this until then as it touches large parts of the auth stack
Can you add this as an idea on GitHub? https://langfuse.com/idea
GitHub
Build software better, together
GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.
sure
In case you currently set langfuse secrets via environment variables: You can also set the apikeys in the Langfuse Client Constructor (all SDKs). This makes it easier to swap them depending on the project
oh ok. that helps, thanks for the info 🙂