Buildxact · API Governance Rules
Buildxact API Rules
Spectral linting rules defining API design standards and conventions for Buildxact.
7 Rules
error 1
warn 4
info 2
Rule Categories
buildxact
Rules
warn
buildxact-info-contact
All Buildxact OpenAPI documents should declare an info.contact with a URL pointing to the developer portal.
$.info
warn
buildxact-summary-title-case
Operation summaries must use Title Case (matches the rest of the api-evangelist catalog).
$.paths.*[get,put,post,delete,patch,options,head].summary
error
buildxact-operation-tags
Every Buildxact operation must declare at least one tag so it can be grouped in docs.
$.paths.*[get,put,post,delete,patch,options,head]
warn
buildxact-operation-description
Operations should describe what they do and call out OData support where applicable.
$.paths.*[get,put,post,delete,patch,options,head]
warn
buildxact-security-headers
Buildxact uses Azure API Management — every operation must require both a subscription key and a bearer token.
$
info
buildxact-odata-page-size
Collection list endpoints should expose $top, $skip, and $count parameters.
$.paths[?(@property =~ /^\/.*s$/)].get.parameters[*].name
info
buildxact-rate-limit-response
Operations should document a 429 response since Buildxact enforces 100 requests / 30 seconds.
$.paths.*[get,put,post,delete,patch].responses