Okta · API Governance Rules
Okta API Rules
Spectral linting rules defining API design standards and conventions for Okta.
10 Rules
error 4
warn 5
info 1
Rule Categories
okta
Rules
error
okta-operation-id-camelcase
Okta operationIds must be camelCase (e.g., listApplications, createUser).
$.paths[*][get,post,put,patch,delete].operationId
warn
okta-operation-summary-title-case
Operation summaries should be Title Case.
$.paths[*][get,post,put,patch,delete].summary
error
okta-operation-must-have-summary
Every operation must have a summary.
$.paths[*][get,post,put,patch,delete]
error
okta-operation-must-have-tag
Every operation must declare exactly one Okta resource tag.
$.paths[*][get,post,put,patch,delete].tags
error
okta-paths-must-be-v1-prefixed
All Management API paths must start with /api/v1/.
$.paths
warn
okta-security-must-be-oauth2-or-apitoken
Okta endpoints should use OAuth2 (scoped) or API Token security.
$.components.securitySchemes
warn
okta-info-must-have-license
The spec must declare Apache-2.0 license to match Okta's published spec.
$.info.license
warn
okta-server-must-be-okta-domain
Server URL should be the parametric Okta subdomain.
$.servers[*].url
info
okta-camelcase-properties
Schema property names should be camelCase (matches Okta's published wire format).
$.components.schemas[*].properties[*]~
warn
okta-deprecated-must-have-description
Deprecated operations must explain replacement in description.
$.paths[*][get,post,put,patch,delete][?(@.deprecated==true)]