Inductive Automation · API Governance Rules
Inductive Automation API Rules
Spectral linting rules defining API design standards and conventions for Inductive Automation.
8 Rules
warn 5
info 3
Rule Categories
ignition
Rules
warn
ignition-operation-must-have-tag
Every operation must have at least one tag matching an Ignition resource area.
$.paths[*][get,post,put,delete,patch]
warn
ignition-operation-must-have-summary
Every operation must have a summary for discoverability.
$.paths[*][get,post,put,delete,patch]
warn
ignition-security-must-be-defined
All Ignition Gateway API operations require authentication via the X-Ignition-API-Token header. Every operation must reference a security scheme.
$.paths[*][get,post,put,delete,patch]
warn
ignition-response-must-include-200
Every operation must define a 200 success response.
$.paths[*][get,post,put,delete,patch].responses
info
ignition-path-must-start-with-data-api
All Ignition Gateway REST API paths follow the /data/api/v1/ prefix pattern. Paths not matching this convention may be legacy WebDev endpoints.
$.paths
info
ignition-resources-path-must-have-collection
Resource paths under /data/api/v1/resources/ must include a fully-qualified collection identifier (e.g., ignition/user-source, com.inductiveautomation.opcua/server-config).
$.paths
warn
ignition-mutative-must-have-request-body
POST and PUT operations against resource endpoints must define a requestBody.
$.paths[*][post,put]
info
ignition-parameter-names-kebab-case
Path parameters should use kebab-case naming as per Ignition API conventions.
$.paths[*][*].parameters[?(@.in == 'path')].name