> ## Documentation Index > Fetch the complete documentation index at: https://docs.qanapi.com/llms.txt > Use this file to discover all available pages before exploring further. # Readiness probe > Requires a working database pool. FIPS state and audit queue depth are reported but do not by themselves fail the probe: a deep queue spills to the write-ahead log rather than losing records, and removing the node from rotation would only push load onto its peers. The detailed body is returned only when the installation sets `EXPOSE_HEALTH_DETAIL`, which it does not outside local environments, because this endpoint answers before authentication. Otherwise only `status` is present. ## OpenAPI ````yaml /openapi/stand-alone/v3.yaml get /health/ready openapi: 3.1.0 info: title: Qanapi Standalone API version: 3.0.0 summary: Single-tenant encryption, key management, classification and audit service. description: > A standalone cryptographic service. Callers hand it data and it returns ciphertext, or hand it ciphertext and it returns data, with every operation authorised by policy and recorded on a tamper-evident audit trail. ## Authentication Two credentials reach the same principal: - **API key** in `X-Qanapi-Authorization`, for machine callers. A key reaches only the configurations it is linked to. - **User bearer token** in `Authorization`, from `POST /api/v3/auth/login`, for a person working through a console. An API key outranks a bearer token when a request carries both, because a key names a narrower credential than the user that owns it. ## Request bodies Endpoints that take a JSON body require `Content-Type: application/json`. The two encryption endpoints are the exception: in whole-body mode they accept any bytes at all, whatever the content type says. ## Errors Every error body carries `message`, which is human readable, and `error`, a stable machine readable code that clients can branch on. Validation failures additionally carry an `errors` object keyed by the field each message concerns; a failure with no single field to blame is filed under `request`. ## Rate limiting Every response carries `X-RateLimit-Limit` and `X-RateLimit-Remaining`. The window is per node and keyed on the client address, so a cluster of n nodes admits n times the configured figure. `POST /api/v3/auth/login` is limited separately and more strictly, ten a minute against sixty, because it needs no credential to reach and each attempt costs a full password verification. A successful login clears that budget, so the stricter limit falls on failed attempts rather than on legitimate sign-ins. ## Correlation Send `X-Request-Id` to tie a request to your own trace. The value is preserved on the audit record and echoed on the response, provided it is at most 64 characters of letters, digits, `-`, `_`, `.` or `:`; anything else is replaced with a generated id. Omit the header and one is generated for you. ## End-to-end encrypted requests and responses Any endpoint accepts a request body wrapped as an RFC 7516 JWE, so the payload is unreadable by anything between your client and this service, including the reverse proxy that terminates TLS. Wrap the JSON body to the key from `GET /api/v3/qanapi-public-key` and send it with `Content-Type: application/jose`; `application/jwt` and `application/jose+json` are accepted too, and a body that is plainly a compact JWE is recognised even without one of those content types. Where the installation requires it, the wrapped payload must carry `iat`, `exp` and `jti` claims, which also make each payload single-use. To have the **response** wrapped in turn, send `X-Qanapi-Wrap-With-Key-Id` naming an RSA key held in this service's KMS that you hold the private half of. The response then arrives as a compact JWE with `Content-Type: application/jose`. The header spelling `wrap_with_key_id` is accepted as well. The wrapping key is resolved with the same permission a plain key read needs, so a caller who may not read that key gets an error instead of a wrapped body. license: name: Proprietary identifier: LicenseRef-Qanapi-Commercial servers: - url: https://{host} description: A deployed instance, behind the reverse proxy that terminates TLS. variables: host: default: qanapi.example.com - url: http://localhost:8000 description: A local cluster, through its load balancer. security: - ApiKeyAuth: [] - BearerAuth: [] tags: - name: STAND Health description: > Liveness and readiness probes. Registered outside the authentication, audit and transport layers, so a load balancer polling them without credentials still gets an answer. - name: STAND Authentication description: > Logging in. There is no registration endpoint: the first administrator is created from the command line on the host, so nothing reachable over the network can claim an installation that has no users yet. Later accounts are created through `POST /api/v3/users`. - name: STAND Users description: User accounts and their roles. - name: STAND API keys description: > Machine credentials. A key is scoped to a set of configurations and reaches nothing until it is linked to at least one. - name: STAND Configurations description: > Encryption configurations. A configuration owns a master key and is the unit of cryptographic isolation. - name: STAND Classifications description: Sensitivity labels and the clearance that reaches them. - name: STAND Policies description: Allow and deny rules binding a principal to actions on resources. - name: STAND Encryption description: > The data plane. Field-level or whole-body encryption under a configuration, optionally forwarded onward to a destination of the caller's choosing. - name: STAND KMS description: Customer-managed key lifecycle, import and export. - name: STAND Audit description: The tamper-evident record of everything the service did. - name: STAND Transport description: The service's own key pair, for end-to-end encrypted request bodies. paths: /health/ready: get: tags: - STAND Health summary: Readiness probe description: | Requires a working database pool. FIPS state and audit queue depth are reported but do not by themselves fail the probe: a deep queue spills to the write-ahead log rather than losing records, and removing the node from rotation would only push load onto its peers. The detailed body is returned only when the installation sets `EXPOSE_HEALTH_DETAIL`, which it does not outside local environments, because this endpoint answers before authentication. Otherwise only `status` is present. operationId: healthReady responses: '200': description: Ready for traffic. content: application/json: schema: $ref: '#/components/schemas/Readiness' '503': description: Not ready; the database pool is unreachable. content: application/json: schema: $ref: '#/components/schemas/Readiness' security: [] components: schemas: Readiness: type: object description: | Only `status` is present unless the installation exposes the detailed body. required: - status properties: status: type: string enum: - ready - unavailable instance_id: type: string database: type: boolean fips: type: object properties: build: type: boolean description: Whether the binary was compiled with the validated module. active: type: boolean description: Whether that module is in FIPS mode at runtime. audit: type: object properties: queue_depth: type: integer metrics: type: object properties: enqueued: type: integer written: type: integer spilled: type: integer description: | Records written to the disk write-ahead log under backpressure. replayed: type: integer dropped: type: integer rejected: type: integer crypto: type: object properties: heavy_permits_available: type: integer description: | Free slots in the concurrency budget for expensive operations such as password hashing and RSA. license: type: object description: The license in force on this node. required: - status - source - expiring_soon properties: status: type: string enum: - active - expired - not_yet_valid - invalid - missing description: | Anything other than `active` refuses new encryption while continuing to serve decryption. source: type: string description: Where the license was read from. licensee: type: string license_id: type: string issued_at: type: string format: date-time expires_at: type: string format: date-time features: type: array items: type: string notes: type: string description: The issuer's free text such as a contract reference.: null key_fingerprint: type: string description: | Identifies the verification key, so one issuer key can be told from its successor without printing either. problem: type: string description: Why nothing is in force when nothing is.: null expiring_soon: type: boolean revocation_epoch: type: integer description: | Incremented by every security-sensitive mutation. Each node polls it and treats cached decisions stamped with an older value as a miss, which is what makes a revocation take effect cluster-wide at once. securitySchemes: ApiKeyAuth: type: apiKey in: header name: X-Qanapi-Authorization description: | A machine credential, `qk_` followed by its secret. Only a hash of the secret is stored, so a key is displayed exactly once, when it is created or rotated. A key reaches only the configurations it is linked to. It may also be sent as `Authorization: Bearer qk_...`, which is recognised by the prefix. BearerAuth: type: http scheme: bearer bearerFormat: JWT description: | A user token from `POST /api/v3/auth/login`. The token asserts a role, but the database decides it, so a role changed or a user deleted after the token was issued takes effect immediately. A token minted before a password change is refused. ````