> ## 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.

# List API keys

> A caller without `apikey:manage` sees only their own keys. Each key is
returned with the configurations it may reach. Not paginated.




## OpenAPI

````yaml /openapi/stand-alone/v3.yaml get /api/v3/api-keys
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/api-keys:
    get:
      tags:
        - STAND API keys
      summary: List API keys
      description: |
        A caller without `apikey:manage` sees only their own keys. Each key is
        returned with the configurations it may reach. Not paginated.
      operationId: listApiKeys
      responses:
        '200':
          description: Keys, each with the configurations it may reach.
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/ApiKey'
        '400':
          $ref: '#/components/responses/NoCredential'
        '401':
          $ref: '#/components/responses/BadCredential'
components:
  schemas:
    ApiKey:
      type: object
      required:
        - id
        - user_id
        - name
        - prefix
        - revoked_at
        - last_used_at
        - created_at
      properties:
        id:
          type: string
          format: uuid
        user_id:
          type: string
          format: uuid
          description: |
            The owning user. Classification clearance for this key resolves
            through this user and their role.
        name:
          type: string
        prefix:
          type: string
          description: |
            The first twelve characters of the key, which is all that is stored
            in readable form. Useful for naming a key in a log without quoting
            the secret.
          examples:
            - qk_Q8oGyqBl3
        revoked_at:
          type:
            - string
            - 'null'
          format: date-time
          description: Null while the key is usable. Revocation is permanent.
        last_used_at:
          type:
            - string
            - 'null'
          format: date-time
        created_at:
          type: string
          format: date-time
        configurations:
          type: array
          description: |
            The configurations this key may reach. An empty array means none:
            the grant is explicit, so a newly minted key cannot touch data until
            somebody says which data it is for.

            Absent, rather than empty, on the response to a rotation, which does
            not load them.
          items:
            type: object
            required:
              - id
              - name
              - proxy_slug
            properties:
              id:
                type: string
                format: uuid
              name:
                type: string
              proxy_slug:
                type: string
    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
  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'
  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.

````