--- title = "Database API 42501 errors" topics = [ "database" ] github_url = "https://github.com/orgs/supabase/discussions/31293" database_id = "49b51a3a-9753-4747-a24e-8afcb075792b" [[errors]] http_status_code = 401 code = "42501" [[errors]] http_status_code = 403 code = "42501" --- [Postgres 42501 errors](https://www.postgresql.org/docs/current/errcodes-appendix.html), often reported by clients as 401 or 403 errors, imply the request lacked adequate privileges. They can be viewed in the [log explorer](/dashboard/project/_/logs/explorer?q=select%0A++++cast%28postgres_logs.timestamp+as+datetime%29+as+timestamp%2C%0A++++event_message%2C%0A++++parsed.error_severity%2C%0A++++parsed.user_name%2C%0A++++parsed.query%2C%0A++++parsed.detail%2C%0A++++parsed.hint%2C%0A++++parsed.sql_state_code%2C%0A++++parsed.backend_type%0Afrom%0A++++postgres_logs%0A++++cross+join+unnest%28metadata%29+as+metadata%0A++++cross+join+unnest%28metadata.parsed%29+as+parsed%0Awhere%0A++++parsed.sql_state_code+%3D+%2742501%27%0Aorder+by%0A++++timestamp+desc%0Alimit+100%3B%0A) by running: ```sql select cast(postgres_logs.timestamp as datetime) as timestamp, event_message, parsed.error_severity, parsed.user_name, parsed.query, parsed.detail, parsed.hint from postgres_logs cross join unnest(metadata) as metadata cross join unnest(metadata.parsed) as parsed where regexp_contains(parsed.error_severity, 'ERROR|FATAL|PANIC') and parsed.sql_state_code = '42501' order by timestamp desc limit 100; ``` They tend to be caused by one of the following factors. ### Attempted to access a forbidden schema API roles cannot access certain schemas, most notably `auth` and `vault`. This restriction extends to Foreign Data Wrappers relying on `vault`. While you can bypass it using a [security definer function](/docs/guides/database/functions?queryGroups=language&language=sql&queryGroups=example-view&example-view=sql#security-definer-vs-invoker), these schemas are intentionally restricted for security reasons. ### Attempted to access a custom schema If you created a custom schema, you will have to give the Database API permission to query it. Follow our [Using Custom Schemas guide](/docs/guides/api/using-custom-schemas) for more directions. ### Missing table-level privileges If you see an error like `permission denied for table your_table`, the querying role may not have the required privilege for the operation. By default, tables in the `public` schema are granted `SELECT`, `INSERT`, `UPDATE`, and `DELETE` to the `anon` and `authenticated` roles. However, you can change these privileges in the [**Integrations > Data API**](/dashboard/project/_/integrations/data_api/settings) section of the Dashboard or via SQL. To check the current privileges on a table: ```sql select grantee, privilege_type from information_schema.role_table_grants where table_name = 'your_table'; ``` To grant a specific privilege to a role: ```sql grant select on table public.your_table to anon; ``` To grant all privileges: ```sql grant select, insert, update, delete on table public.your_table to anon, authenticated; ``` Granting privileges allows access to your table through the Data API, so you should ensure you [enable RLS](/docs/guides/database/postgres/row-level-security) and write appropriate policies to protect your data. For more information, see [Securing your API](/docs/guides/api/securing-your-api). ### Configured column-level restrictions If you've set column-based access in the [Dashboard](/dashboard/project/_/database/column-privileges) or via SQL, queries will fail with a `42501` error when accessing restricted columns. This includes using `select *`, as it expands to include forbidden columns. ### RLS: If the anon or authenticated roles attempt to UPDATE or INSERT values without the necessary RLS permissions, Postgres will return a 42501 error.