> ## 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. # Export, and optionally purge, audit records > Requires `audit:export`, and `audit:purge` as well when purging. Streams matching records as JSON Lines or CSV, oldest first, optionally gzipped. One export covers at most 100,000 records; narrow the filters and repeat if you have more. The filters are the ones the query endpoint accepts, sent in the body; `page` and `per_page` are accepted and ignored. With `purge` set, the exported records are deleted in the same transaction that read them, so nothing can be purged that was not successfully exported. A purge is itself recorded, with the window it covered, so a later chain verification can tell an authorised purge apart from tampering. The body is optional; send none to export everything in the default format. ## OpenAPI ````yaml /openapi/stand-alone/v3.yaml post /api/v3/audit-logs/export 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: /api/v3/audit-logs/export: post: tags: - STAND Audit summary: Export, and optionally purge, audit records description: | Requires `audit:export`, and `audit:purge` as well when purging. Streams matching records as JSON Lines or CSV, oldest first, optionally gzipped. One export covers at most 100,000 records; narrow the filters and repeat if you have more. The filters are the ones the query endpoint accepts, sent in the body; `page` and `per_page` are accepted and ignored. With `purge` set, the exported records are deleted in the same transaction that read them, so nothing can be purged that was not successfully exported. A purge is itself recorded, with the window it covered, so a later chain verification can tell an authorised purge apart from tampering. The body is optional; send none to export everything in the default format. operationId: exportAuditLogs requestBody: required: false content: application/json: schema: $ref: '#/components/schemas/ExportRequest' responses: '200': description: | The export stream. `Content-Type` follows `format`, and a gzipped export is the same content type under `Content-Encoding: gzip` rather than a type of its own. headers: Content-Disposition: description: | Names a generated file, `audit-.`, with `.gz` appended when the export is gzipped. schema: type: string examples: - attachment; filename="audit-20260917T101500Z.jsonl" Content-Encoding: description: Present, and `gzip`, only when `gzip` was requested. schema: type: string const: gzip X-Qanapi-Audit-Records: description: How many records the export contains. schema: type: integer X-Qanapi-Audit-Chain-Verified: description: | Whether the hash chain over the exported records verified. A `false` here is a compliance event in its own right, and the export is still returned so it can be examined. schema: type: string enum: - 'true' - 'false' content: application/x-ndjson: schema: type: string text/csv: schema: type: string '400': $ref: '#/components/responses/NoCredential' '401': $ref: '#/components/responses/BadCredential' '403': $ref: '#/components/responses/Forbidden' '409': description: | The matching records changed while a purging export was running, so nothing was purged and nothing was returned. Retry it. content: application/json: schema: $ref: '#/components/schemas/Error' '422': $ref: '#/components/responses/ValidationFailed' components: schemas: ExportRequest: type: object description: | Accepts every filter the query endpoint accepts, plus the three fields at the end. `page` and `per_page` are accepted and ignored: an export covers the whole matching range up to its ceiling. properties: from: type: string format: date-time to: type: string format: date-time action: type: string description: An exact action, or a `kms.*` style prefix. configuration_id: type: string format: uuid principal_id: type: string principal_type: type: string enum: - user - api_key - anonymous - system status: type: string enum: - success - denied - error request_id: type: string instance_id: type: string format: type: string enum: - jsonl - csv default: jsonl description: | `jsonl` streams one JSON record per line; `csv` flattens them into a header row and one row per record. gzip: type: boolean default: false description: | Compress the stream. Signalled by `Content-Encoding`, not by a different content type. purge: type: boolean default: false description: | Delete the exported records in the same transaction that read them, so nothing is purged that was not successfully exported. Requires `audit:purge`, and is itself recorded with the window it covered. Error: type: object required: - message - error properties: message: type: string description: | Human readable. A server-side fault is described by its category and nothing more: operational detail stays in the service's own log. examples: - Unauthorized. error: type: string description: | A stable machine readable code. Branch on this rather than on `message`, which is shared between conditions that this code tells apart. examples: - InvalidApiKeyException ValidationError: allOf: - $ref: '#/components/schemas/Error' - type: object required: - errors properties: errors: type: object description: > Messages keyed by the field they concern. A failure with no single field to blame is filed under `request`. additionalProperties: type: array items: type: string examples: - type: - The type field is required. configuration_ids: - No configuration has the id `...`. responses: NoCredential: description: | No credential was presented. Send an API key in `X-Qanapi-Authorization`, or a bearer token in `Authorization`. content: application/json: schema: $ref: '#/components/schemas/Error' BadCredential: description: A credential was presented and did not verify. content: application/json: schema: $ref: '#/components/schemas/Error' Forbidden: description: | Authenticated, but not permitted. Also returned for a revoked API key. content: application/json: schema: $ref: '#/components/schemas/Error' ValidationFailed: description: | The request body or a parameter is invalid. `message` is always `Validation failed`; the specifics are in `errors`, keyed by field. content: application/json: schema: $ref: '#/components/schemas/ValidationError' 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. ````