LiveKit API secret consistently 43 characters instead of 44 — getting persistent 401 invalid token

Getting Started
,
1

Hi everyone,

I’m running into a persistent issue with LiveKit Cloud credentials.

Every time I create a new API key from my project (vp-live-2txwwmuh), the API Secret comes out as 43 characters instead of 44. I’ve tried generating multiple new keys, but the result is always the same.

Because of this, I’m getting a 401 “invalid token” error when validating the credentials, even though:

  • The project slug matches the WebSocket URL
  • The API Key format looks correct
  • I’ve copied using the Copy button and triple-click method

LiveKit keeps rejecting the secret with “invalid token”. Has anyone else run into the secret being generated as 43 characters instead of 44?

Any advice would be greatly appreciated.

Thanks!

2

I don’t think it’s the secret length, can you try generating the token using the LiveKit CLI, then try connecting to a room with that token? That isolates the token generation logic.

lk token create

I’d say the most common root cause for this type of issue is the API secret used to generate the token does not match the one associated with the API key in your project.

3

Update on persistent 43-character API secret issue (multiple fresh keys tested)

Hi LiveKit Community and Darryn,

Following up on my original post. I’ve continued investigating the consistent 43-character secret length instead of the expected 44.

What I’ve done so far:

  • Created multiple new API keys from the same project.
  • Always used the official Copy button in the “Key generated” popup (never manual highlighting).
  • Tested pasting into Notepad first to verify the full string before putting it into my .env.
  • Installed and used the LiveKit CLI (lk cloud auth + lk token create).
  • At one point I successfully obtained a 44-character secret.
  • When I revoked that working 44-character key and created a replacement, the new key came back as 43 characters again.

Current behavior:

  • My local validation script (check:livekit) now correctly detects length 44 in some cases, but the LiveKit admin API probe still fails with 401 invalid token.
  • When the secret is 43 characters, the validation explicitly flags it and skips the admin API probe.
  • The issue has remained reproducible across several key generations.

It now looks like there may be a pattern where revoking a 44-character secret results in the next newly generated key returning 43 characters.

Has anyone else seen new keys generated after revocation coming back short? Or is there something on the Cloud side that could cause secret length to drop on subsequent key creation for the same project?

Any guidance would be appreciated. Happy to provide more details or outputs from lk token create / validation if helpful.

Thanks!

4

Are you sure your system clock is correct? Can you share a token you generated and the exact time it was created?

5

Thank you for the suggestion to check the system clock.

I have now removed Ubuntu from my dual-boot setup. I went into the ThinkPad BIOS and excluded the Ubuntu boot entry (it now shows with a white X). I plan to restart the laptop after posting this.

Regarding the credential issue:

  • I followed the recommended clean process: deleted all old API keys, created one fresh key, and copied the WebSocket URL + API Key + Secret directly using the official Copy buttons.
  • I also tested pasting into Notepad first before updating my .env.
  • My local validation script now accepts 43-character secrets and runs the real admin API probe.
  • However, I am still getting 401 Unauthorized on:
    • lk room list
    • The LiveKit admin API probe during startup validation

I’ve confirmed that JWT signing works locally and the iss claim matches the API key. The rejection is happening server-side on LiveKit Cloud.

Current values in .env (from the latest fresh key):

  • LIVEKIT_URL: wss://vp-live-2txwwmuh.livekit.cloud
  • LIVEKIT_API_KEY: API98v3RvL5erwW
  • LIVEKIT_API_SECRET: [43 characters – redacted]

Question:
After excluding Ubuntu in the BIOS, is it recommended to restart before further testing, or does it not significantly affect the credential/clock issue?

Any additional guidance on why a freshly created key/secret pair from the same project continues to return 401 would be very helpful.

Thanks again!

6

OS should not matter. You did not share a token that failed and what time you created.

I am pretty sure the 44/43-character that you mention is a red-herring and is just happens to be a b64 padding difference.

7

Thank you for the clarification.

I haven’t shared a failing token yet. I’ll generate one now using the LiveKit CLI with the current credentials and note the exact creation time.

Would you prefer I share:

  • The full token, or
  • Just the decoded claims from jwt.io (especially the iat / nbf / exp timestamps)?

I’ll also restart my laptop first (I recently removed Ubuntu from dual-boot) before generating the test token, in case the clock was affected.

8

I would like the full token and exact time you generated it. If I had to bet I would bet that your system clock that generates the token is not correct.

I am also suspicious of the URL you are using since I don’t see any requests to vp-live-2txwwmuh.livekit.cloud. Are you sure that is correct?

See here:
https://cloud.livekit.io/projects/p_/settings

9

Generated at: 2026-06-29 13:10 EDT (using lk token create --valid-for 5m)

Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJBUEk5OHYzUnZMNUVyd1ciLCJzdWIiOiJkZWJ1Zy11c2VyIiwibmJmIjoxNzUxMjA5NDUwLCJleHAiOjE3NTEyMDk3NTAsInZpZGVvIjp7InJvb21Kb2luIjp0cnVlLCJyb29tIjoidGVzdC1kZWJ1Zy1yb29tIn19. [rest of the token]

FYI - I was trying to keep my project quiet for a time begins hence I kept some info back a little. Sorry if that is the issues here. With the link you edited - am I the only one can viewing it?

10

This token is not valid. Looks like it got truncated or somehting.

11

If I manually decode the base64 it looks like it expired 1751209750 → 2025-06-29 15:09:10 a year ago.

...
"nbf":1751209450,
"exp":1751209750,
...
12

Sorry, the token got truncated in my previous post. It was generated with lk token create --valid-for 5m.

After cleaning up old keys and using the correct Cloud URL, both npm run check:livekit and lk room list now succeed with no 401 errors.

I’ll test the actual Square video chat connection next over ngrok.

13

Everything is working on my end. Thank you.

This post can close earlier if need to be.