Skip to content
ReviveDB
Blog

Supabase OAuth cannot read Realtime or Storage configuration

By AK

Project configuration is separate from the database. We tested the four relevant Management API endpoints with an OAuth app token. Auth and PostgREST worked; Realtime and Storage did not.

The four configuration endpoints

Reading a project's configuration means calling four separate Management API endpoints, one per subsystem:

  • GET /v1/projects/{ref}/config/auth: auth providers, JWT expiry, redirect URLs.
  • GET /v1/projects/{ref}/postgrest: the REST API config, meaning exposed schemas and max rows.
  • GET /v1/projects/{ref}/config/realtime: Realtime channel configuration.
  • GET /v1/projects/{ref}/config/storage: Storage configuration, separate from the files themselves.

Two of them work, two don't

With an OAuth access token, config/auth and postgrest return 200. The other two return 401:

HTTP 401: "GET /v1/projects/{ref}/config/realtime does not support oauth access yet"

The same OAuth restriction also affects GET /v1/profile for sign-in and on the JIT database endpoints. The exact responses differ: /profile, /database/jit/list, Realtime and Storage return the explicit "does not support oauth access yet" message, while POST /database/jit returns HTTP 406 "Failed to get user's JIT access for project". Realtime and Storage config accept the personal access tokens the Supabase CLI uses, but not OAuth application tokens. No scope you can request changes it; re-authorizing doesn't help.

Retested on 5 August 2026

  • GET /config/auth → HTTP 200 with the OAuth app token
  • GET /postgrest → HTTP 200 with the OAuth app token
  • GET /config/realtime → HTTP 401 "does not support oauth access yet"
  • GET /config/storage → HTTP 401 "does not support oauth access yet"

How we report the missing coverage

ReviveDB records Auth and API settings from the endpoints that work. Realtime and Storage configuration are marked unavailable through OAuth, rather than reported as backed up. If Supabase opens those endpoints, they can be added to the same capture and restore flow.

A tool claiming full configuration coverage through Supabase OAuth should explain how it reads these two endpoints. A personal access token is a different, broader credential and should not be presented as equivalent to scoped OAuth access.

The database in every ReviveDB recovery point is restored and checked. Storage files and Function bundles are checked by hash, and the Supabase backup page lists the current coverage limits.