Limble CMMS · API Governance Rules
Limble CMMS API Rules
Spectral linting rules defining API design standards and conventions for Limble CMMS.
7 Rules
error 1
warn 4
info 2
Rule Categories
limble
Rules
warn
limble-operation-tags
Every operation should have at least one tag for grouping in docs.
$.paths[*][get,post,patch,put,delete]
warn
limble-operation-summary
Every operation should have a summary for clarity.
$.paths[*][get,post,patch,put,delete]
error
limble-response-200-or-201
Every operation must define at least one success response (200 or 201).
$.paths[*][get,post,patch,put,delete].responses
warn
limble-id-field-integer
Limble resource ID fields (e.g. assetID, taskID, partID) should be typed as integer to match the API's convention.
$.components.schemas[*].properties[*ID]
warn
limble-basic-auth-security
Limble API uses HTTP Basic authentication; every operation should either inherit the global security scheme or declare it explicitly.
$.components.securitySchemes
info
limble-pagination-params
Collection GET endpoints (listing resources) should support pagination parameters (page, limit or offset) to allow clients to page through large result sets.
$.paths[*].get.parameters[*]
info
limble-location-header-on-create
POST operations that return 201 Created should include a Location response header pointing to the new resource, per the Limble API convention.
$.paths[*].post.responses.201.headers