mirror of
https://github.com/supabase/supabase.git
synced 2026-10-10 03:45:06 +03:00
Pamela ChiaandAleksi Immonen
35531ea2f4
Agent-readiness scanners and agent fetchers look for an OpenAPI spec at conventional same-origin paths, but the Management API spec is only served on api.supabase.com and linked from the /.well-known/api-catalog linkset, which scanners do not read. I added a rewrite so supabase.com/openapi.json proxies the spec from its source of truth at api.supabase.com/api/v1-json, using the same fall-through proxy mechanism as /humans.txt and /evals. **Note:** no cache or CORS headers on purpose: no consumer needs them today, and the upstream response's set-cookie header defeats edge caching regardless. I rejected a checked-in copy of the spec in favor of proxying live (staleness). The /.well-known/api-catalog linkset already points at the spec (PR #44880) and is untouched here; this PR only adds the conventional same-origin path. **Merge order:** merge only after supabase/platform#37571 deploys. The spec currently ships `servers: []`, so OpenAPI consumers resolve relative paths against the fetch origin; without the platform fix this proxy would point spec-compliant clients at supabase.com/v1/*. ## To test Tested on Vercel preview: - [x] `curl -s https://<preview-url>/openapi.json | head -c 40` returns `{"openapi":"3.0.0"` - [x] `curl -sI https://<preview-url>/openapi.json` returns 200 with `content-type: application/json` - [x] `curl -sI https://<preview-url>/humans.txt` returns 200 (control: rewrite fall-through chain intact) ## Linear - fixes GROWTH-1138 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added access to the OpenAPI specification at `/openapi.json`. * Requests are automatically routed to the API specification endpoint. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Aleksi Immonen <aleksi@supabase.io>