New secret API keys (sb_secret_...) return 401 on PostgREST and Auth admin but work on Storage

[oyakubu11-cell]

Project ref: gvfuhykpegzyqktddnca (Free plan, region eu-central-1)

Our new secret API keys (sb_secret_..., both the auto-created "default" one and a newly created one) are accepted by the Storage API but rejected with an empty-body HTTP 401 on the Data API (PostgREST) and on Auth admin.

What we tested (same key each time, project restarted once, on 2026-10-07):

• GET /rest/v1/articles?select=id&limit=1 with the header apikey: -> 401 (empty body)
• same request with Authorization: Bearer added -> 401
• GET /auth/v1/admin/users?per_page=1 -> 401
• POST /storage/v1/object/list/podcast -> 200; uploading and deleting a test object -> 200
• same REST request with our legacy service_role JWT -> 200
• requests with no key, or with a fake sb_secret_ key, are rejected on Storage with 400, so the real key is recognised there.

Context: the JWT Signing Keys page shows current key = ECC (P-256) and previous key = Legacy HS256 (rotated about a month before the test). PostgREST 14.5, Auth 2.197.0, Postgres 17.6.1.166.

Question: is something missing on our project for the Data API and Auth to accept the new secret keys? We want to migrate off the legacy service_role JWT and then revoke the legacy HS256 key. We opened a support ticket (SU-497409) on 2026-10-07 and only received the automatic acknowledgement.

Thank you.

[kamilkaczmareksolutions]

the first thing i'd rule out is where the requests come from. secret keys are blocked for browsers: Supabase matches on the User-Agent header and returns 401 (API keys docs). if the REST and Auth tests ran from a browser console, from a REST client that sends a browser user agent, or from code that runs in the browser, that alone gives you a 401 with an empty body

quick check from a terminal, with the key only on apikey:

curl -i "https://<project-ref>.supabase.co/rest/v1/articles?select=id&limit=1" \
  -H "apikey: sb_secret_..."

also keep the new keys off Authorization: Bearer. they aren't JWTs, and the docs say to send them on apikey (see "Known limitations" on the same page)

if plain curl with only apikey still returns 401 while Storage accepts the same key, it's on the platform side and the ticket is the right place. add the full response headers of the failing call to it

[oyakubu11-cell]

Thank you, that was it. My earlier REST and Auth tests were run from a browser context. From a terminal, with the key on the apikey header only, REST and Auth admin both return 200, and a request with a browser User-Agent returns 401 “Forbidden use of secret API key in browser”, as documented. Issue solved, I’ll close the support ticket.