Supabase Storage /object/info with legacy API keys disabled

[EDIPT-Studio]

I'm looking for clarification on Supabase Storage authentication with the newer API-key model.

My project has intentionally disabled the legacy anon / service_role API keys and is using the newer publishable/secret key model.

Current observations:

• Storage API version: 1.77.5
• /storage/v1/version → HTTP 200
• A known Storage object exists.
• Requests using the old legacy service_role key are rejected because legacy API keys are disabled.
• A request to:
  /storage/v1/object/info/{bucket}/{path}
  using the current sb_secret_... key returns HTTP 400 with an empty response body.

I have a deployment-readiness check that currently expects the legacy SUPABASE_SERVICE_ROLE_KEY and uses the /storage/v1/object/info/{bucket}/{path} endpoint to verify authenticated Storage access.

My question: With legacy API keys disabled, is /storage/v1/object/info/{bucket}/{path} still the correct/supported endpoint for verifying authenticated access to an existing Storage object? If yes, what is the recommended authentication method/key type for this check when using the new API-key model?

I'm trying to determine whether my verification method needs to be updated for the new API-key model. I do not want to re-enable legacy keys or make unnecessary production changes.

Thanks!

[GaryAustin1]

If you are using sb_secret_..... then you only put that in the apikey header if you are doing direct API requests. You can't put it in the authorization header.

[EDIPT-Studio]

Thanks for the clarification about sb_secret_... — I tested again using the secret key only in the apikey header, with no Authorization header.

I'm still getting:

• GET /storage/v1/object/info/{bucket}/{path} → HTTP 400
• POST /storage/v1/object/list/{bucket} → HTTP 400
• GET /storage/v1/version → HTTP 200, Storage version 1.77.5

The legacy service_role key is intentionally disabled in this project, so I'm trying to verify the correct authentication method for Storage using the new API-key model.

Could you clarify:

1. Should sb_secret_... work directly against the Storage API using only the apikey header?
2. If yes, is /storage/v1/object/list/{bucket} expected to work with a secret key?
3. Is there a different recommended Storage endpoint for verifying authenticated backend access with a secret key?

I'm specifically trying to determine whether my Storage verification test is using the wrong endpoint/request format, rather than re-enabling legacy API keys.

Thanks!

[EDIPT-Studio]

hey. are you there ?

[GaryAustin1]

Those endpoints all work for me on my project using apikey with the sb_secret_... key. On the list one you do need to add the body with something like {"prefix":"","limit":100,"offset":0,"sortBy":{"column":"name","order":"asc"}}

[EDIPT-Studio]

thanks. that works for me.