Files
certctl/docs/reference/api.md
T
shankar0123 e7509ddad8 docs: factuality sweep — fix 3 broken links + 12 count claims (audit findings 2026-05-05)
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 commit cb154a8)

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 commit a3599ad (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.
2026-05-05 06:15:35 +00:00

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 number
  • per_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 response
  • page_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:

  1. Open Postman → Import → File → select api/openapi.yaml
  2. Postman creates a collection with every documented operation organized by tag
  3. Set the baseUrl variable to https://localhost:8443 (HTTPS-only as of v2.2)
  4. Add an Authorization: Bearer your-api-key header to the collection
  5. Import the demo stack CA bundle (deploy/test/certs/ca.crt) into Postman's Settings → Certificates → CA Certificates, or disable certificate verification for the localhost host (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