Supabase Storage: Management API sees private buckets, but Storage data plane does not

[EDIPT-Studio]

I’m troubleshooting a Supabase project using the current publishable/secret API-key model.

The Management API reports multiple private Storage buckets for the project.

However, requests to the project’s Storage endpoint currently return:

Storage /version:
HTTP 200  1.77.5

REST /rest/v1/ with publishable key:
HTTP 401

REST /rest/v1/ with secret key:
HTTP 401

GET /storage/v1/bucket with publishable key:
HTTP 200  []

GET /storage/v1/bucket with secret key:
HTTP 400

GET /storage/v1/object/info/<private-bucket>/<known-object>
with secret key:
HTTP 400

The Storage /version endpoint is reachable, but the Storage data plane does not appear to resolve the private buckets reported by the Management API.

For the Storage requests, the secret key is sent only as:

apikey: <secret-key>

There is no Authorization: Bearer header.

I previously had an independent read-only test against the same project where an object-info request returned HTTP 200 with version and last_modified, but I can no longer reproduce that result.

Question: Could this indicate:

1. an invalid/stale secret key or project/key-resolution issue,
2. a Storage gateway/tenant synchronization issue, or
3. expected behavior/another authentication requirement with the current API-key model?

What is the recommended read-only diagnostic for distinguishing an API-key problem from a Storage data-plane/tenant problem?

[GaryAustin1]

Does the key working on a database table from the REST API?
Check the storage log for errors.
No other reports like this that I've seen.

[EDIPT-Studio]

Thanks. I’ll check whether the same publishable/secret key works against a normal database table through the REST API and review the Storage logs for errors.

The important detail is that /storage/v1/version returns 200, while the Storage bucket/object requests behave differently depending on the key, and the REST API returns 401 with both keys.

I’ll use read-only requests only and compare the results to determine whether this is a key-resolution/authentication issue or a Storage data-plane/tenant synchronization issue.