---
number: 42949
slug: 42949-breaking-change-removing-access-to-openapi-spec-via-the-anon-key
published: 2026-02-17
discussion: https://github.com/orgs/supabase/discussions/42949
labels:
  - postgrest
  - breaking-change
page: https://supabase.com/changelog/42949-breaking-change-removing-access-to-openapi-spec-via-the-anon-key
---

# Breaking Change: Removing access to OpenAPI spec via the anon key

## What’s Changing?

The Data API returns the full OpenAPI spec for any schema exposed to the Data API at the root path: `https://[projectref].supabase.co/rest/v1/`

Starting March 11, we will begin deprecating support for accessing this endpoint via the `anon` key. You will get the following error message if this endpoint is accessed via the `anon` key

```
{"message":"Access to schema is forbidden","hint":"Accessing the schema via the Data API is only allowed using a secret API key."}
```
The endpoint remains accessible and the behaviour doesn't change if you are using the service role keys or the new secret API keys. 

**This does not affect normal Data API usage.** Accessing data via `/rest/v1/your_table` or any client library will continue to work exactly as they do today. 

## Why?

Today, the endpoint returns schema details (tables, columns, and types of an exposed schema) to anyone with the `anon` key. While this does not expose actual row data, it provides more information about your schema than most production applications need.

As part of an ongoing effort to tighten default security across Supabase, we are removing this exposure. In practice, the schema spec is mostly useful during development, where you can use the `service_role` key. There are few cases where you would need it client-side in production (less than 0.1% of our projects have made a request to this endpoint using the `anon` key in the last 24 hours), and we do not think supporting those use cases is worth the security tradeoff.

## Am I Affected?

You are affected if your app currently uses the `anon` key to fetch the Swagger spec.

You can check by reviewing requests to the `/rest/v1/` endpoint via [this log query](https://supabase.com/dashboard/project/_/logs/edge-logs?s=/rest/v1/+).

If you see requests:
1. Click into the event.
2. Check whether the request is coming from the `anon` role.

## What Should I Do?

1. Check your logs. Use the log query above to see if any of your application traffic relies on this endpoint with the `anon` key.
2. Move affected calls server-side If your application fetches the schema spec, move that call to a server-side context like Edge Functions where you can safely use the `service_role` or the [new secret API keys](https://supabase.com/blog/jwt-signing-keys#1-migrate-to-get-started).   

## Rollout and Communications Timeline

| Date      | Change                                                                 |
|-----------|------------------------------------------------------------------------|
| 17 Feb    | Changelog published                                                    |
| 4 March   | Change announced in monthly newsletter                                 |
| 6 March   | Email notification to customers observed using this endpoint           |
| 11 March  | Newly created projects cannot access endpoint with `anon` key          |
| 24 March  | Final email notification to customers observed using this endpoint     |
| 8 April   | All existing projects cannot access endpoint with `anon` key           |

We may push these dates back based on customer feedback, but we will not move them forward.

## What’s Next?

This is the first in a series of changes we are making to tighten default security settings across Supabase. Stay tuned for improvements to RLS usability, default table grants, and additional security features.

## Update 23.03.2026

We now have a new Management API endpoint for the CLI and third party integration that only requires the "Read-only project database access" permission. Details are [here](https://supabase.com/docs/reference/api/v1-get-database-openapi).