Supabase: Invalid API key / legacy API keys disabled
Invalid API key
In short: The key your app sends doesn't match the project, or it's a legacy anon/service_role key that has been disabled.
Why it happens
Supabase is moving from the legacy JWT anon / service_role keys to publishable (sb_publishable_...) and secret (sb_secret_...) keys, and its docs say the legacy keys are being deprecated by the end of 2026. Tutorials and AI tools often still produce the old long eyJ... keys. Other causes: the URL and key are from different projects, a stray space or quote in the env var, or a secret key used in a browser (Supabase rejects secret keys sent from browsers).
How to fix it
- In the dashboard, open Project Settings → API Keys and copy the publishable key for client code.
- Make sure the project URL and key come from the same project.
- Update the env var on your machine and on your host, then restart and redeploy.
- Keep secret keys only in server code (route handlers, Edge Functions).
- If you disabled legacy keys, search the codebase for any remaining
eyJ...keys oranonkey references.
Copy-paste fix prompt
I'm getting this error in my app: Invalid API key [Paste the full error, stack trace, and the file it points to here] Likely cause: The key your app sends doesn't match the project, or it's a legacy anon/service_role key that has been disabled. Task: Find every place the Supabase client is created, check which key each uses and where it runs (browser vs. server), and switch client code to the publishable key and server code to a secret key from server-only env vars. Rules: - First explain the root cause in 2 sentences and list the files you'll change. - Make the smallest change that fixes it. Don't refactor unrelated code. - Don't disable security or checks (RLS, auth, signature verification, type checking, CORS allow-all) to make the error disappear. - Never print or hard-code secret keys. - Finish by telling me exactly how to verify the fix.
Common with: Lovable, Bolt, Cursor, v0. Last reviewed 2026-11-13.