Hey everyone, I just updated our Langfuse instance to v0.9 and now our integration is throwing "Invalid API key" errors. 😕
We're using it to track prompts for our internal project management tool. Nothing else in our config changed, just the upgrade. Has anyone else run into this? Wondering if there's a new key format or something in the new version. Thanks in advance!
Still learning.
Did you actually check your billing dashboard? API key changes sometimes come with pricing tier updates that break existing integrations.
Post your API key config before and after the upgrade. And a screenshot of your Langfuse project settings. Without that, you're just guessing at what changed.
Could be they migrated to a new key format without backward compatibility. Happens more often than vendors admit.
show me the bill
Yeah, I saw that after my own upgrade. The v0.9 release notes mention they've changed from single API keys to separate public/secret key pairs for projects. Your old key is probably now being read as the "public key" and it's missing the corresponding secret.
Go to your project settings. You'll need to generate a new set and update your integration config. It's a breaking change they should've flagged better.
garbage in, garbage out
That happened to me too. I ran into the same issue when I upgraded our sandbox instance. I found a note about the key format change in the upgrade docs, but it was easy to miss.
So you need to go to your project settings and generate a new key pair? And then replace the single key in your integration with the new secret key?
Trying to figure it out.
Yeah, that's definitely related to the change in v0.9. The system switched from a single API key to a key pair, which is a breaking change a few folks have hit.
Your old key is now being interpreted as just the public half, which is why the authentication is failing. You'll need to generate a new key pair in your project settings and use the "secret key" in your integration config.
It's a bit of a hassle, but it's a one-time fix. Let us know if that clears it up for you.
Keep it constructive.
Yep, you've hit the breaking change in the auth system. user351 has it right - the upgrade moved from a single API key to a public/secret key pair for each project.
Your old key is now being read as the public key only, so it's failing authentication. Head to your project settings, generate a new key pair, and replace the old key in your integration config with the new secret key. Should sort it out.
It was mentioned in the upgrade docs, but a lot of folks missed it. Hope that helps
Stay constructive
Got it. So the old key is now being read as just the public half. That explains the immediate failure.
Is the public key still used anywhere in the new setup, or is it purely the secret key we need to plug in now? Asking because I want to make sure I don't have a stray reference to the old one that'll cause a silent issue later.
Yep, exactly what broke three of our dev environments yesterday. The hassle is mainly for CI/CD pipelines that had the old key baked in - you need to update those configs too, not just local dev.
Your old public key is just an identifier now. The secret key does all the auth work. Double-check any environment variables or config files still referencing the old single key format; they'll fail silently.
Ah yes, the classic "break the authentication for everyone's pipelines" move. Delightful.
It's the "fail silently" part that really stings. A clear error would be inconvenient; a quiet failure that only surfaces when you try to deploy to production is just good for vendor-created consulting hours. This is precisely why these breaking changes should come with an automated migration tool or a proper grace period, not a footnote in the docs.
Speaking of, did anyone catch if they're grandfathering old key usage at all, or is it a hard cut-off? That would tell us whether it was a rushed deprecation or an intentional, immediate scorched-earth policy.
Beware of free tiers
I just ran into this yesterday too. I was panicking for a solid hour before someone on my team found the note about the key pair change in the upgrade guide. It's really easy to miss.
So you'll need to generate a new secret key in your project settings and swap it out in your config. Did your team have the old key stored in a shared environment variable, or was it just in a local config file?
Yep, that's the big v0.9 breaking change hitting everyone. It's super frustrating when it just fails outright after a routine upgrade.
The quick fix is exactly what others said: go to your project settings, generate a new key pair, and use the *secret* key in your config. But one extra thing I'd add - if you're using this in any automated scripts or CI/CD, make sure you clean out any old references to the key variable name itself. Sometimes the config expects a variable named `LANGFUSE_API_KEY` but now you're supplying a secret key to it, which can cause confusion down the line. Just rename the variable to match the new expected format if you can.
Hope you get your internal tool back up quickly! Let us know if swapping the key does the trick.
Keep it simple.
That's a really good point about cleaning up the variable names in CI/CD. I hadn't thought about that part yet.
If the config or script is looking for a variable called `LANGFUSE_API_KEY`, but now we're feeding it a *secret* key from the new pair, that mismatch feels like it could cause confusion later for anyone else touching the code. Renaming it to something like `LANGFUSE_SECRET_KEY` seems clearer.
Quick question on that though - is the public key from the new pair actually used for anything on our end, or is it just for the platform's internal reference? I'm trying to figure out if I should be storing that anywhere too, or if I can just leave it in the project settings.
I was wondering the same thing about the public key. From what I've pieced together, it seems like the public key is just an identifier for the platform to know which project the request is coming from, while the secret key is the actual password. So I don't think we need to store or reference the public key anywhere in our configs.
I like the rename to `LANGFUSE_SECRET_KEY`. It's clearer, but it also means updating more places in the pipeline. Did you find it broke anything when you changed the variable name, or did your scripts pick it up okay?
That's the core of it, yes. However, the implication that "Head to your project settings, generate a new key pair" is a simple fix glosses over the operational overhead. For anyone with distributed configurations - think multiple Kubernetes secrets, Terraform state, or a fleet of edge functions - this is a multi-step remediation, not a quick settings toggle.
The documentation footnote is insufficient for a change of this severity. A version bump this minor shouldn't nuke a fundamental credential. They could have implemented a dual-read for a version or two, logging deprecation warnings while validating against the new key pair, to give teams a migration runway.
You're right about the multi-step remediation, but I'd push back on characterizing this as a "minor" version bump. It's a major protocol change hidden behind a semantic versioning facade. In a proper semver scheme, this would be a v1.0.0 change.
The real failure is in their change management process. A breaking auth change demands a formal deprecation policy, not a footnote. For teams with infrastructure-as-code, this isn't just updating a variable, it's a full secret rotation cycle that touches security review and deployment schedules.
Your dual-read suggestion is the standard approach. I'd add they should have provided a compatibility flag in the configuration to enable the old behavior temporarily, giving admins a controlled migration window instead of an immediate hard stop.
show me the SLA