/api/auth/setup returns 401 Unauthorized after deploying (Kinde Next.js SDK)

Not specified by the original author.

TL;DR

Fixed upstream in PR #268 (the setup flow handling); upgrade @kinde-oss/kinde-auth-nextjs to a release from February 2025 or later containing that fix. The maintainers confirmed the fix in the thread after discussing the deploy-vs-local difference internally.

Steps

1. Fixed upstream in PR #268 (the setup flow handling); upgrade @kinde-oss/kinde-auth-nextjs to a release from February 2025 or later containing that fix. The maintainers confirmed the fix in the thread after discussing the deploy-vs-local difference internally. If the 401 persists on a current SDK version, double-check that the deployed environment serves the same auth routes as local, since a missing route produces the same symptom.
2. Take the question above and check if it matches what you're seeing. If it does, work through the verified fix step by step. Start with the cause described first, because that's what tells you the fix applies to your setup, then apply the changes in the order given. Verify by re-running whatever failed before, and expect the same behavior the thread author reported.

When to use

You are seeing this: The /api/auth/setup route in @kinde-oss/kinde-auth-nextjs returned 401 Unauthorized after deployment, while everything worked locally. Use this skill when you run into "/api/auth/setup returns 401 Unauthorized after deploying (Kinde Next.js SDK)".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Someone asked: The /api/auth/setup route in @kinde-oss/kinde-auth-nextjs returned 401 Unauthorized after deployment, while everything worked locally. The setup endpoint rejected the request in the production environment with no useful error beyond the 401. Local dev and production behaved differently, which pointed at the SDK's setup flow rather than the app's configuration. The verified answer: Fixed upstream in PR #268 (the setup flow handling); upgrade @kinde-oss/kinde-auth-nextjs to a release from February 2025 or later containing that fix. The maintainers confirmed the fix in the thread after discussing the deploy-vs-local difference internally. If the 401 persists on a current SDK version, double-check that the deployed environment serves the same auth routes as local, since a missing route produces the same symptom. Source: https://github.com/kinde-oss/kinde-auth-nextjs/issues/170 Discussion and confirmation live at https://vectle.com/threads/thr5qHnip03dtNzvj9H75pIQ

Not specified by the original author.

TL;DR: 400s only in production while the tunneled dev setup works. The code is identical; the secret is not. Confirm the cause 1. Check which instance's endpoint page you copied the whsec_ secret from.

The fix

1. Development and production are separate Clerk instances with separate webhook endpoints and separate signing secrets.
2. Check which instance's endpoint page you copied the whsec_ secret from. If it was the development instance, production verification can never pass.
3. Confirm the production endpoint URL registered in the dashboard matches your deployed URL exactly (https, correct path).
4. Copy the signing secret from the PRODUCTION instance's endpoint page into your production env vars, keeping the dev secret in dev.
5. Never commit either secret to the repo; both live in env vars or your secret manager.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: Webhooks verify locally but fail in production.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current Webhooks behavior.

Verified against Clerk webhook docs and deployment guides 2026-09-26: each webhook endpoint has its own signing secret shown on its settings page; dev and production are separate instances with separate keys, and the deployment guide calls out forgetting to switch keys as the common production mistake.

Not specified by the original author.

TL;DR: The frontend refuses to load Clerk, or backend calls return 401. One of the two keys is sitting in the other's slot. Confirm the cause 1. Both keys must come from the SAME instance.

The fix

1. Publishable keys start with pk and belong on the frontend: ClerkProvider and NEXTPUBLIC_ variables. They are safe to expose.
2. Secret keys start with sk and belong ONLY on the backend, for createClerkClient and direct Backend API calls. A secret key in a NEXTPUBLIC_ variable ships it to every browser.
3. If the frontend complains: you likely pasted a secret key into the publishable slot, or there is a typo or stray whitespace.
4. If the Backend API 401s: you likely passed the publishable key where the secret key belongs.
5. Both keys must come from the SAME instance. A pktest key paired with an sklive key never works.
6. Put each key in its slot, trim whitespace, restart the dev server so env changes load, and re-check the prefixes.

When to use this

• You are seeing this exact error message; match the block above, not just part of it.
• The failing call matches the scenario in the title: 'Invalid publishable key' or Backend API 401.
• You want the fastest verified fix before digging through logs.

When not to use this

• Your error text differs from the block above; close cousins often have different causes.
• The stack trace points at a different component than the one in the title.
• You already applied this fix and the error persists; look for a second cause instead of reapplying.

Compatibility

• Not pinned to a specific version; follows current 'Invalid behavior.

Verified against Clerk deployment docs 2026-09-26: the publishable key (pktest in development, pklive in production) is passed to ClerkProvider during initialization; the secret key (sktest/sklive) is used to access the Backend API. Forgetting to switch keys per environment is the documented common mistake.