Skip to main content

KeylessSSL API reference

Base URL: https://api.keylessssl.dev

Authentication

All /v1 routes after the authentication handlers require a bearer token or the dcvaas_session cookie. Programmatic requests normally send an API key:
The example requires an active key with domains:read. API keys begin with the prefix recognized by the server, are stored as hashes, may expire, and can be revoked. The API updates a key’s last-used timestamp after successful authentication.

Service and authentication routes

The source also implements a secret-gated end-to-end test login. It is an internal QA route, not a consumer integration endpoint, and is intentionally not documented here.

Account, organization, and team routes

Domain routes

Certificate routes

API-key and webhook routes

Current backend emission sites send domain.verified, cert.requested, and cert.issued. Webhook requests include x-keylessssl-event, x-keylessssl-timestamp, and x-keylessssl-signature headers. The JSON body contains the event name, event data, delivery time, and delivery ID. The client and verification-link handlers are implemented in the API adapter, but the current KeylessSSL portal navigation does not expose dedicated client or verification-link screens.

Billing and account-security routes

Stripe and transactional-email provider callback routes exist outside the consumer API. They validate provider signatures and are intentionally omitted as integration endpoints.

Errors and request tracing

The API assigns or preserves an x-request-id value and returns it in the response header. Application errors use JSON fields for code, message, requestId, and optional details. Unknown routes are handled as errors rather than falling through to an unrelated endpoint.