Support Custom Rulesets for Spectral Linter in API Validation

[RusJaI]

Current Limitation

Currently in API Manager, the Spectral linter–based API validation is performed using the default oas ruleset from @stoplight/spectral-rulesets.

When minor (patch) versions of the OpenAPI Specification are released, Spectral appears to align with the latest available patch version when applying its validation rules.

In a recent customer issue, we observed that the customer’s API definition conforms to OAS 3.0.0 and is successfully validated using the Swagger Editor. However, since API Manager performs UI-level validation using the Spectral linter, the validation failed due to rules aligned with OAS 3.0.3.

This behavior has impacted the customer’s contract-first development approach, as the same API definition is considered valid in one tool but invalid in another due to differences in patch-level rule alignment.

Suggested Improvement

To prevent inconsistencies in the linter used by API Manager for API-level validation, and to better support customer-specific validation requirements, it would be beneficial to introduce an option that allows users to define and apply custom Spectral rulesets.

With such an enhancement, the system could continue to use spectral-rulesets:oas as the default ruleset, while providing the flexibility to override it with a user-defined custom ruleset when needed.

This custom ruleset could be introduced either as:

• A separate file, or

• An additional field within the tenant-level configurations.

Providing this capability would help mitigate inconsistencies arising from third-party linter behavior and version alignment, while also enabling customers to tailor validation rules according to their specific governance and contract requirements.

Version

4.3.0