API Docs Guardrails
Validate API documentation standards. Ensures repositories with APIs have valid specification files with human-readable documentation. Operates on protocol-agnostic `.api.spec_files[]` for universal checks across all API protocols (REST, gRPC, GraphQL).
api-docs to your lunar-config.yml:uses: github://earthly/lunar-lib/policies/api-docs@v1.0.0
Included Guardrails
This policy includes 3 guardrails that enforce standards for your repository and ownership.
spec-exists
Verifies that at least one API specification file exists in the repository
by checking if .api.spec_files[] is non-empty. Protocol-agnostic — works
for REST (OpenAPI/Swagger), gRPC (protobuf), or any future API format.
Skips if neither the openapi nor swagger collector has run.
spec-valid
Checks that all detected API spec files parse without errors by verifying
.api.spec_files[].valid is true for every entry.
Skips if no spec files were detected.
has-docs
Checks that all API spec files include human-readable documentation
(descriptions, examples) by verifying .api.spec_files[].has_docs is
true for every entry. A bare definition without descriptions doesn't
count. Skips if no spec files were detected.
How Guardrails Fit into Lunar
Lunar guardrails define your engineering standards as code. They evaluate data collected by integrations and produce pass/fail checks with actionable feedback.
Policies support gradual enforcement—from silent scoring to blocking PRs or deployments—letting you roll out standards at your own pace without disrupting existing workflows.
Learn How Lunar Works →Example Evaluated Data
This policy evaluates structured metadata from the Component JSON. Here's an example of the data it checks:
{
"api": {
"spec_files": [
{
"path": "api/openapi.yaml",
"format": "openapi",
"protocol": "rest",
"valid": true,
"version": "3.0.3",
"operation_count": 12,
"schema_count": 5,
"has_docs": true
}
],
"native": {
"openapi": {
"api/openapi.yaml": {
"openapi": "3.0.3",
"info": { "title": "User API", "version": "1.0.0" },
"paths": { "...": "full raw spec" }
}
}
}
}
}
Required Integrations
This policy evaluates data gathered by one or more of the following integration(s).
Make sure to enable them in your lunar-config.yml.
Configuration
Configure this policy in your lunar-config.yml.
Inputs
| Input | Required | Default | Description |
|---|
Documentation
View on GitHubAPI Docs Guardrails
Enforce API documentation standards for OpenAPI/Swagger specifications.
Overview
Validates that repositories with APIs maintain proper documentation through specification files. Operates on protocol-agnostic .api.spec_files[] — all checks work for any API type (REST, gRPC, GraphQL). Deep inspection uses raw native specs under .api.native.*.
All checks skip gracefully when no API spec files are detected.
Policies
| Policy | Description |
|---|---|
spec-exists |
At least one API spec file detected in the repository |
spec-valid |
All detected spec files parse without errors |
has-docs |
All spec files include human-readable documentation (descriptions, examples) |
Required Data
This policy reads from the following Component JSON paths:
| Path | Type | Provided By |
|---|---|---|
.api.spec_files[] |
array | openapi collector |
.api.spec_files[].valid |
boolean | openapi collector |
.api.spec_files[].has_docs |
boolean | openapi collector |
Note: Enable the openapi collector before using this policy. For version enforcement (Swagger 2.0 → OpenAPI 3.x migration), see the openapi policy.
Installation
Add to your lunar-config.yml:
policies:
- uses: github://earthly/lunar-lib/policies/api-docs@main
on: ["domain:your-domain"]
enforcement: report-pr
# include: [spec-exists] # Only run specific checks (omit to run all)
Examples
Passing Example
Repository with a valid, documented OpenAPI 3.x spec:
{
"api": {
"spec_files": [
{
"path": "api/openapi.yaml",
"format": "openapi",
"protocol": "rest",
"valid": true,
"version": "3.0.3",
"operation_count": 12,
"schema_count": 5,
"has_docs": true
}
],
"native": {
"openapi": {
"api/openapi.yaml": { "...": "full raw spec" }
}
}
}
}
Failing Example — No Spec
Repository with no API spec files:
{}
Failure message: "No API specification file found"
Failing Example — Invalid Spec
{
"api": {
"spec_files": [
{
"path": "api/openapi.yaml",
"format": "openapi",
"protocol": "rest",
"valid": false,
"version": null,
"operation_count": 0,
"schema_count": 0,
"has_docs": false
}
]
}
}
Failure message: "API spec file api/openapi.yaml failed to parse"
Failing Example — No Documentation
A bare spec with no descriptions or examples:
{
"api": {
"spec_files": [
{
"path": "api/openapi.yaml",
"format": "openapi",
"protocol": "rest",
"valid": true,
"version": "3.0.3",
"operation_count": 8,
"schema_count": 3,
"has_docs": false
}
]
}
}
Failure message: "API spec api/openapi.yaml has no documentation (descriptions, examples)"
Remediation
When these policies fail, you can resolve them by:
- spec-exists: Add an OpenAPI or Swagger specification file to your repository (e.g.
openapi.yaml). - spec-valid: Fix syntax errors in your spec file. Use a linter like Spectral to validate.
- has-docs: Add
descriptionfields to your operations, schemas, and parameters. Useexampleorexamplesto document expected values.
Open Source
This policy is open source and available on GitHub. Contribute improvements, report issues, or fork it for your own use.
Common Use Cases
Explore how individual guardrails work with specific integrations.
Ready to Automate Your Standards?
See how Lunar can turn your engineering wiki, compliance docs, or postmortem action items into automated guardrails with our 100+ built-in guardrails.