Create custom API style rules to enforce your organization's specific guidelines.
Rules are defined in JSON format within a style profile:
{
"id": "URI-001",
"title": "Use plural resource names",
"category": "uri-design",
"severity": "error",
"rationale": "Plural resources improve consistency and make the API more intuitive.",
"examples": {
"good": ["/users", "/orders", "/products"],
"bad": ["/user", "/order", "/product"]
},
"enforcement": {
"type": "spectral",
"given": "$.paths[*]~",
"function": "pattern",
"options": {
"match": "^/[a-z]+s(/|$)"
}
}
}| Field | Type | Description |
|---|---|---|
id |
string | Unique identifier (e.g., URI-001, HTTP-002) |
title |
string | Short, descriptive title |
category |
string | Rule category for grouping |
severity |
string | error, warn, info, or hint |
| Field | Type | Description |
|---|---|---|
rationale |
string | Why this rule exists |
examples |
object | Good and bad examples |
enforcement |
object | Spectral rule configuration |
judge |
object | LLM evaluation configuration |
conformanceLevel |
string | bronze, silver, or gold |
references |
array | External documentation links |
For deterministic, pattern-based checking:
{
"enforcement": {
"type": "spectral",
"given": "$.paths[*]~",
"function": "pattern",
"options": {
"match": "^/[a-z-]+$"
}
}
}Common Spectral functions:
| Function | Use Case |
|---|---|
pattern |
Regex matching |
truthy |
Value must be present |
falsy |
Value must be absent |
enumeration |
Value must be in list |
length |
String/array length |
schema |
JSON Schema validation |
For semantic analysis that can't be captured by patterns:
{
"judge": {
"criteria": "Does the API use consistent terminology throughout?",
"passCriteria": "All endpoints use the same terms for similar concepts",
"failCriteria": "Different terms are used for the same concept (e.g., 'user' vs 'account')",
"weight": 0.8
}
}{
"$schema": "https://api-style-spec.dev/schema/v1/api-style-spec.schema.json",
"name": "my-company-style",
"version": "1.0.0",
"description": "My Company API Style Guidelines",
"extends": ["default"],
"rules": []
}{
"rules": [
{
"id": "MYCO-001",
"title": "Use company standard error format",
"category": "errors",
"severity": "error",
"rationale": "Consistent error handling across all APIs",
"enforcement": {
"type": "spectral",
"given": "$.components.schemas[?(@.title == 'Error')]",
"function": "truthy"
}
}
]
}{
"extends": ["default"],
"overrides": {
"URI-001": {
"severity": "warn"
}
}
}Organize rules into logical categories:
| Category | Description |
|---|---|
uri-design |
URL structure and naming |
http-methods |
HTTP verb usage |
status-codes |
Response status codes |
request-response |
Payload structure |
errors |
Error handling |
security |
Authentication/authorization |
versioning |
API version management |
documentation |
Descriptions and examples |
{
"id": "DOC-001",
"title": "Operations must have operationId",
"category": "documentation",
"severity": "error",
"enforcement": {
"type": "spectral",
"given": "$.paths[*][get,post,put,patch,delete]",
"then": {
"field": "operationId",
"function": "truthy"
}
}
}{
"id": "VER-001",
"title": "Use semantic versioning",
"category": "versioning",
"severity": "error",
"enforcement": {
"type": "spectral",
"given": "$.info.version",
"function": "pattern",
"options": {
"match": "^\\d+\\.\\d+\\.\\d+$"
}
}
}{
"id": "SEC-001",
"title": "Use HTTPS only",
"category": "security",
"severity": "error",
"enforcement": {
"type": "spectral",
"given": "$.servers[*].url",
"function": "pattern",
"options": {
"match": "^https://"
}
}
}- Create a test OpenAPI spec with known violations
- Run the linter with your custom profile
- Verify expected violations are reported
api-style lint test-spec.yaml --profile ./my-company-style.json- Specification Format - Complete schema reference
- CLI Reference - Command documentation