Per the cowork/docs-audit-2026-05-05/ end-to-end factuality audit (20 confirmed findings across 76 docs, 7 parallel subagents + audit-of-the-audit). Hot + Warm tier fixes ship here; STALE findings (qa-test-suite.md test-count snapshot) need 'make qa-stats' which is operator-side. BROKEN links repaired (3): - docs/reference/api.md L195: [Quick Start](quickstart.md) → ../getting-started/quickstart.md (404 pre-fix) - docs/reference/api.md L196: [Connector Guide](connectors.md) → connectors/index.md (Phase 4 rename, was 404 pre-fix) - docs/reference/protocols/scep-intune.md L377: [legacy-est-scep.md](legacy-est-scep.md) → scep-server.md (file was deleted in Phase 7 commite9b1510) INCORRECT count claims repaired (12): - api.md L5 + L18-19 + L155: '78 API operations' / '# 78' / 'all 78 documented operations' → re-derive via grep -cE '^\s+operationId:' (actual at HEAD: 144) - architecture.md L66 (Mermaid label) + L502 + L1047 + L1253: '8 always-on + 4 optional loops' / '12-loop topology' → 9 always-on + 5 opt-in loops (14 total). Always-on/opt-in breakdown derived from cmd/server/main.go startup wiring: always-on are agentHealthCheck, crlGeneration, jobProcessor, jobRetry, jobTimeout, notificationProcess, notificationRetry, renewalCheck, shortLivedExpiryCheck (9); opt-in are networkScan, digest, healthCheck, cloudDiscovery, acmeGC (5). Re-derive count via grep -cE '^func \(s \*Scheduler\) [a-zA-Z]+Loop' internal/scheduler/scheduler.go. - configuration.md L31: '12 loops, 8 always-on + 4 opt-in' → '14 loops, 9 always-on + 5 opt-in'. Self-introduced regression from commit3275f9f(2026-05-05). - mcp.md L11 + L65: 'all 78 API endpoints' / '78 available tools' → re-derive via grep -cE 'mcp\.AddTool\(' (actual at HEAD: 87 MCP tools, 144 API operations). - connectors/index.md L111: '9 built-in' issuer connectors → '12 built-in', extending the inline enumeration to include Entrust, GlobalSign, EJBCA (which had been added since the L111 prose was written). Local-CA framing extended to mention tree mode + ADCS sub-CA mode-doc. - connectors/index.md L112: '14 built-in' target connectors → '15 built-in', adding AWS ACM target + Azure Key Vault target (which had been added since the L112 prose was written). - why-certctl.md L37 + the inline list: 'Nine issuer connectors ship today' → 'Twelve issuer connectors', adding AWS ACM PCA, Entrust, GlobalSign, EJBCA to the list and removing the misleading 'EST enrollment' bullet (EST is a protocol surface, not an issuer; clarified in trailing note). - why-certctl.md L66: '13 deployment targets' → '15', adding Kubernetes Secrets, AWS ACM, and Azure KV to the inline list. - why-certctl.md L92: 'supports 9 issuer types' → '12 issuer types'. - quickstart.md L135: '35 demo certificates across 5 issuers' → re-derive cert count via 'grep -oE "mc-[a-z0-9_-]+" migrations/seed_demo.sql | sort -u | wc -l' (actual: 32, matches README L86; quickstart was off-by-3). - quickstart.md L452 (Demo Data Reference table): Certificates '35' → '32' (matches the cert count from seed_demo.sql). Verification: - grep confirms no remaining stale refs across the touched files (8 files, 31 insertions / 28 deletions). - All 24 ci-guards/*.sh pass locally. - The audit's STALE findings (S-1, S-2 qa-test-suite.md Bundle-P snapshot) are operator-side: run 'make qa-stats' to refresh the Test Suite Health table. Companion: cowork/docs-audit-2026-05-05/RESULTS.md captures the full audit with subagent false positives and missed findings called out.
6.8 KiB
OpenAPI Specification Guide
Last reviewed: 2026-05-05
certctl ships with a complete OpenAPI 3.1 specification at api/openapi.yaml. The spec documents every operation (re-derive count via grep -cE '^\s+operationId:' api/openapi.yaml), every request/response schema, pagination conventions, authentication requirements, and error formats. It's the single source of truth for the documented REST API.
This guide covers how to use the spec for API exploration, client SDK generation, and integration testing.
Where to Find It
The spec lives at api/openapi.yaml in the repository root. It's versioned alongside the code and updated with every API change.
# View the spec
cat api/openapi.yaml
# Count operations (includes health + ready)
grep -cE '^\s+operationId:' api/openapi.yaml
Viewing with Swagger UI
The fastest way to explore the API interactively is Swagger UI. Run it as a Docker container pointing at the spec:
# From the certctl repo root
docker run -p 8080:8080 \
-e SWAGGER_JSON=/spec/openapi.yaml \
-v $(pwd)/api:/spec \
swaggerapi/swagger-ui
Open http://localhost:8080 to see the full API reference with "Try it out" buttons for every endpoint.
Alternatively, use Redoc for a cleaner read-only view:
docker run -p 8080:80 \
-e SPEC_URL=/spec/openapi.yaml \
-v $(pwd)/api:/usr/share/nginx/html/spec \
redocly/redoc
API Structure
The spec organizes endpoints into 16 tags:
| Tag | Endpoints | Description |
|---|---|---|
| Certificates | 12 | CRUD, versions, renewal, deployment, revocation, deployments |
| CRL & OCSP | 3 | JSON CRL, DER CRL per issuer, OCSP responder |
| Issuers | 5 | CA connector management |
| Targets | 5 | Deployment target management |
| Agents | 7 | Registration, heartbeat, CSR submission, work polling |
| Jobs | 5 | Job queue with approve/reject |
| Policies | 5 | Policy rules and violations |
| Profiles | 5 | Certificate enrollment profiles |
| Teams | 5 | Team management |
| Owners | 5 | Certificate owners |
| Agent Groups | 5 | Dynamic agent grouping |
| Audit | 2 | Immutable audit trail |
| Notifications | 3 | Notification events |
| Stats | 5 | Dashboard statistics |
| Metrics | 1 | System metrics |
| Health | 3 | Health, readiness, auth info |
Authentication
The spec declares a bearerAuth security scheme applied globally. All endpoints under /api/v1/ require a Bearer token by default:
# The default compose stack uses a self-signed cert; pin with --cacert
curl --cacert ./deploy/test/certs/ca.crt \
-H "Authorization: Bearer your-api-key" \
https://localhost:8443/api/v1/certificates
Three endpoints are exempt from auth (declared with security: [] in the spec): /health, /ready, and /api/v1/auth/info. The auth info endpoint tells clients whether authentication is enabled and what type is required — useful for GUIs that need to show/hide a login screen.
Pagination Convention
All list endpoints follow the same pagination pattern:
Request parameters:
page(integer, default 1) — page numberper_page(integer, default 50, max 500) — results per page
Response envelope:
{
"data": [...],
"total": 150,
"page": 1,
"per_page": 50
}
Certificates also support cursor-based pagination for large datasets:
cursor(string) — opaque cursor token from previous responsepage_size(integer) — results per page when using cursor mode
Generating Client SDKs
The OpenAPI spec can generate typed client libraries for any language. Here are examples using common generators:
TypeScript (openapi-typescript-codegen)
npx openapi-typescript-codegen \
--input api/openapi.yaml \
--output src/generated/certctl \
--client axios
Python (openapi-python-client)
pip install openapi-python-client
openapi-python-client generate --path api/openapi.yaml
Go (oapi-codegen)
go install github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen@latest
oapi-codegen -generate types,client -package certctl api/openapi.yaml > certctl_client.go
Java (OpenAPI Generator)
npx @openapitools/openapi-generator-cli generate \
-i api/openapi.yaml \
-g java \
-o generated/java-client
Validating the Spec
Verify the spec is valid OpenAPI 3.1:
# Using spectral (recommended)
npx @stoplight/spectral-cli lint api/openapi.yaml
# Using swagger-cli
npx @apidevtools/swagger-cli validate api/openapi.yaml
Using with Postman
Import the spec directly into Postman:
- Open Postman → Import → File → select
api/openapi.yaml - Postman creates a collection with every documented operation organized by tag
- Set the
baseUrlvariable tohttps://localhost:8443(HTTPS-only as of v2.2) - Add an
Authorization: Bearer your-api-keyheader to the collection - Import the demo stack CA bundle (
deploy/test/certs/ca.crt) into Postman's Settings → Certificates → CA Certificates, or disable certificate verification for thelocalhosthost (Settings → General → SSL certificate verification)
Key Schemas
The spec defines typed schemas for all domain objects. Key schemas to know:
| Schema | Description |
|---|---|
ManagedCertificate |
Core certificate record with status, expiry, owner, tags, profile |
CertificateVersion |
Individual cert version with PEM, serial, fingerprint, validity |
Agent |
Agent with heartbeat, metadata (OS, arch, IP, version), capabilities |
Job |
Job record with type, status (7 states), certificate/target references |
PolicyRule |
Policy with type (5 types), config, severity, enabled state |
CertificateProfile |
Enrollment profile with allowed key types, max TTL, constraints |
AuditEvent |
Immutable audit record with actor, action, resource, timestamp |
RevocationReason |
RFC 5280 reason code enum (8 values) |
DashboardSummary |
Aggregate stats (total certs, expiring, agents, jobs) |
Integration Testing
Use the spec to generate contract tests that verify the API matches the spec:
# Using schemathesis for fuzz testing against the spec
pip install schemathesis
# The default compose stack uses a self-signed cert — export a CA bundle or set REQUESTS_CA_BUNDLE
export REQUESTS_CA_BUNDLE=$(pwd)/deploy/test/certs/ca.crt
schemathesis run api/openapi.yaml \
--base-url https://localhost:8443 \
--header "Authorization: Bearer your-api-key"
This sends randomized valid requests to every endpoint and verifies the responses match the declared schemas.
What's Next
- MCP Server Guide — AI-native access to the certctl API
- Quick Start — Get certctl running locally
- Connector Guide — Build custom issuer and target connectors
- Architecture — System design deep dive