Supabase · API Governance Rules
Supabase API Rules
Spectral linting rules defining API design standards and conventions for Supabase.
11 Rules
error 1
warn 8
info 2
Rule Categories
supabase
Rules
warn
supabase-operation-ids-camel-case
Supabase operation IDs must use camelCase (e.g. listProjects, createProject)
$.paths[*][get,post,put,patch,delete].operationId
warn
supabase-tags-title-case
All tags must use Title Case
$.tags[*].name
warn
supabase-operation-tags-title-case
All operation tags must use Title Case
$.paths[*][get,post,put,patch,delete].tags[*]
warn
supabase-summaries-title-case
Operation summaries must use Title Case
$.paths[*][get,post,put,patch,delete].summary
warn
supabase-project-ref-variable
Server URLs with per-project base URLs must use {project_ref} variable naming convention
$.servers[*].variables
warn
supabase-security-apikey-or-bearer
Supabase APIs use either apikey header authentication, Bearer JWT authentication, or both. Every operation should specify security.
$.paths[*][get,post,put,patch,delete]
info
supabase-error-responses
Operations should document 401 Unauthorized responses
$.paths[*][get,post,put,patch,delete].responses
warn
supabase-request-body-post
POST operations creating resources should have a request body
$.paths[*].post
info
supabase-operation-description
All operations should have a description
$.paths[*][get,post,put,patch,delete]
warn
supabase-info-contact
APIs must include contact information
$.info
error
supabase-servers-defined
APIs must define at least one server
$