Indian Institute of Technology Bombay · API Governance Rules
Indian Institute of Technology Bombay API Rules
Spectral linting rules defining API design standards and conventions for Indian Institute of Technology Bombay.
7 Rules
error 3
warn 4
Rule Categories
info
operation
path
property
servers
Rules
error
operation-has-operationId
Every operation should carry an operationId. This API already does, 164/164.
$.paths[*][get,put,post,delete,patch]
warn
operation-described
Operations should carry a description or summary. 99 of 164 do; the 65 that do not are mostly autogenerated CRUD routes.
$.paths[*][get,put,post,delete,patch]
warn
operation-declares-error-response
Every operation should declare at least one 4xx response. None of the 164 currently do, while the deployed API returns 401, 403 and 404 in practice. This is the single largest contract gap in IIT Bombay's public footprint.
$.paths[*][get,put,post,delete,patch].responses
warn
property-name-snake-case
Property names should be snake_case or a single lowercase word — this API's convention at 368/370.
$.components.schemas[*].properties
warn
path-segment-not-camel-case
Path segments should be lowercase or kebab-case. Five segments break this (/alumniLogin, /alumniOTP, /getEncr, /getUserMess, /resendAlumniOTP) against 181 that do not.
$.paths
error
info-contact-email
info.contact.email should be present — it is what makes an operator attributable.
$.info.contact
error
servers-declared
servers[] must be present and non-empty. Recorded explicitly because a per-tag refine split is known to drop the top-level servers block, which would erase the one piece of evidence that this contract is the institution's and not a vendor's.
$
Spectral Ruleset
Work with this as data
Every ruleset here is available over the APIs.io API and to AI agents over MCP.