Rulesets

​

What a Ruleset Is

​

Ruleset Components

• Rules: Individual checks that validate specific aspects of a service definition.
• Severity Levels: Each rule carries a severity of Error, Warn, or Info that determines how strongly the rule’s outcome affects compliance. See Severity and Compliance.
• Validation Functions: The specific logic used to evaluate service definitions against rules. Tyk Governance ships with built-in functions covering the common cases.
• Remediation Guidance: Per-rule “How to fix” guidance authored alongside the rule itself, displayed inline against any service that fails the rule.

# Security rule requiring HTTPS for server URLs
hosts-must-use-https:
  description: All server URLs MUST use the https protocol
  severity: error
  given: $.servers[*].url
  then:
    function: pattern
    functionOptions:
      match: "^https://"
  howToFix: "Update server URLs in your API definition to use the https scheme."

# Ensure rateLimit is configured under upstream
rate-limit-exists:
  description: Ensure rateLimit exists under upstream
  severity: error
  given: "$['x-tyk-api-gateway'].upstream"
  then:
    field: rateLimit
    function: truthy
  howToFix: "Add a rateLimit configuration under x-tyk-api-gateway.upstream."

​

Spectral Compatibility

• Familiar Format: Teams already using Spectral can migrate their existing rulesets without rewriting them.
• Ecosystem Integration: You can use the broader ecosystem of pre-built Spectral rules.
• High-Performance Execution: Tyk Governance executes rulesets using the Vacuum engine, a high-performance Go-based linter that is fully compatible with the Spectral ruleset format and significantly faster than Spectral on large service specifications.

​

Create a Ruleset

​

From a Template

1. Define basic information: name, description, Deployment Warning toggle, and API Categories.
2. Choose starting point: select Start from template.
3. Browse templates: choose from the templates available in your environment.
4. Review and edit: the template’s JSON loads into the editor. Adjust as needed.

​

From Your Own Definition

​

Configure a Ruleset

​

Basic Settings

• Status: Inactive, which does not evaluate services, or Active, which evaluates all mapped services.
• Name: Required, and unique within the organization.
• Description: Long-form description.
• Link ruleset to services (Category): Multi-select. The ruleset evaluates services in any of the selected categories.
• Deployment Warning toggle: Off by default. When on, saving a non-compliant service in a matching category produces a soft warning at deploy time. See The Deployment Warning.

​

Raw Definition

​

Test a Ruleset Against a Service

• From the ruleset’s detail page, described below. Select any service and run the current ruleset against it. Use this when you are authoring the ruleset.
• From the Governance tab on a service. Run any ruleset against that one service. Use this when you own the service. See Service Compliance.

1. Open the ruleset’s detail page.
2. In the Test ruleset panel, select a service from the dropdown.
3. Click Run ruleset.
4. Review the issues returned, graded by severity.

• Reviewing a ruleset before activating it: run a draft ruleset against a representative service to see what would be flagged, then refine the rules before linking the ruleset to a category.
• Iterating on rule severity or definitions while editing the Raw definition.
• Spot-checking an individual service against a ruleset that is not currently linked to its category.

​

Find a Ruleset in the List

• Status: Active or Inactive. Inactive rulesets do not evaluate services.
• Name: Click to open the ruleset’s detail page.
• Category: The API Categories the ruleset is linked to.
• Deployment Warning: Whether the warning toggle is on or off.
• Last updated: When the ruleset was most recently modified.
• Actions: View or edit the ruleset.

​

Delete a Ruleset

​

Run a Ruleset From a Pipeline

​

Best Practices

• Start with templates. The OWASP API Security and Vacuum-Recommended templates cover most baseline cases without requiring custom authoring.
• Use clear, actionable howToFix text. When a rule fires, the API owner should be able to act on the guidance immediately.
• Keep rulesets focused. A ruleset of 200 mixed-purpose rules is harder to maintain than three rulesets of 60 each, organized by domain such as security, design, and documentation.
• Use the test sandbox before activating. Run a draft ruleset against representative services before linking it to live categories, especially when promoting rules to Error severity.
• Assign clear ownership. Document which team or individual owns each ruleset, so changes go through a sensible review.

​

FAQ