> ## Documentation Index
> Fetch the complete documentation index at: https://docs.parmanasystems.com/llms.txt
> Use this file to discover all available pages before exploring further.

# List approver keys

> Lists every approver key the server trusts, or once trusted, to sign human approvals for policies that require one.



## OpenAPI

````yaml openapi.bundled.yaml GET /approval-issuers
openapi: 3.1.0
info:
  title: Parmana API
  version: 1.0.0
  description: >
    Parmana sits between an AI agent and the systems it acts on. An agent sends
    a Business Transaction: who

    authorized it, what action it wants, and the facts that justify it. Parmana
    evaluates the policy bound to

    the action, checks any signed human approval the policy requires, releases
    the action to the connector

    only if the policy approves, and returns a signed Execution Trust Record
    anyone can verify.


    **Authentication.** Send `Authorization: Bearer <key>` on every request. The
    only routes that need no key

    are the probes, the documents and the independent verification routes: `GET
    /health`, `GET /ready`,

    `GET /openapi.yaml`, `GET /openapi.json`, `GET /api-manifest.json`, `GET
    /documentation`,

    `GET /reference`, `GET /parmana-handbook.pdf`, `GET
    /handbook/download-leads`,

    `POST /handbook/download-leads`, `POST /refusal/verify`, `POST
    /execution-intents/verify`,

    `POST /audit/verify`, `GET /keys/{keyId}` and `GET /.well-known/jwks.json`.
    A missing or unknown key

    returns `401` before anything else runs. The server holds only a hash of
    each key. See

    [Authentication](/api-reference/authentication).


    **Two kinds of key.** An agent or service key may invoke only the
    capabilities listed on it. A human key

    (`credentialHolderType: USER`) is required for governance: proposing and
    approving policies, approvers

    and external connectors, and repairing Execution Intents. Approving or
    rejecting a change also needs a

    step up authorization signed with the checker's own step up key, and the
    checker must not be the

    person who proposed it.


    **Ownership.** Every lookup by `businessTransactionId` is scoped to the key
    that submitted the

    transaction. A transaction submitted by another key returns the same `404`
    as one that does not exist.


    **Try it live.** The first server below is the public sandbox,
    `https://parmana-sandbox.vercel.app`: the same

    code as production with its own database, keys and demo approver, whose one
    action, `sandbox:receipt`,

    acts on nothing. Every "Try it" panel calls it with the published demo key
    prefilled. The demo key may

    invoke only `sandbox:receipt`, so other capabilities return `403` and
    governance routes return

    `403 NON_HUMAN_CALLER_DENIED`. Everything sent to the sandbox is visible to
    every visitor. See

    [Playground](/playground). Production needs a key issued by its operator.


    **Start here:** the [Playground](/playground) (no install), the
    [Quickstart](/quickstart), then [Integrate Parmana](/agents/integrate) for
    agents

    and [Connect any external system](/guides/connect-any-external-system) for
    your own endpoint.
  contact:
    name: Parmana Systems
    email: founder@parmanasystems.com
  license:
    name: Proprietary, source-available for evaluation only, see LICENSE
    url: https://github.com/pavancharak/parmana/blob/main/LICENSE
servers:
  - url: https://parmana-sandbox.vercel.app
    description: >-
      Public sandbox (the docs playground). Same code as production, demo data
      only, acts on nothing. Demo key prefilled.
  - url: https://parmana-api-real.vercel.app
    description: Production. Needs a key issued by the operator.
  - url: http://localhost:3000
    description: Local (packages/api, PORT env var, default 3000)
security:
  - bearerAuth: []
tags:
  - name: Execution
    description: >-
      Executes a Business Transaction through the complete Execution Trust
      pipeline
  - name: Transactions
    description: Business Transaction creation and retrieval
  - name: Verification
    description: Deterministic verification of an Execution Trust Record
  - name: Receipts
    description: Cryptographically signed Execution Trust Receipts
  - name: Trust Records
    description: Execution Trust Record retrieval
  - name: Replay
    description: Deterministic replay of a recorded Execution Trust Record
  - name: Policies
    description: Policy existence/readability check
  - name: Policy Governance
    description: Maker-checker proposal, listing, approval, and rejection of policy changes
  - name: Approvers
    description: Maker-checker for the keys trusted to sign approvals, without a deploy
  - name: External Connectors
    description: >-
      Maker-checker for binding a capability to an operator's HTTPS endpoint and
      its policy, without a deploy (ADR-0013)
  - name: Business Signal Sources
    description: >-
      Maker-checker for the business systems Parmana asks for the facts a policy
      needs, without a deploy (RFC-0023)
  - name: Authority Grants
    description: >-
      Maker-checker for which agent may have which action decided, within which
      limits, until when (RFC-0023)
  - name: Sandbox
    description: >-
      Routes that exist only on the public sandbox (ADR-0014), for trying
      Parmana from a browser
  - name: Refusal Records
    description: >-
      Durable, signed evidence that a policy decision rejected a transaction
      (RFC-0021)
  - name: Execution Intents
    description: >-
      A signed statement, stored before an action is released, of exactly what
      is about to be released, plus the operator tools to find and repair a
      released action that has no signed Trust Record (ADR-0012)
  - name: Audit
    description: >-
      Signed caller-authentication audit events, independently
      third-party-verifiable
  - name: System
    description: Operational endpoints
paths:
  /approval-issuers:
    get:
      tags:
        - Approvers
      summary: List approver keys
      description: >
        Lists every approver key the server trusts, or once trusted, to sign
        human approvals for policies

        that require one. Keys in the server code come first (`source: code`),
        then keys added through

        approver changes (`source: governed`). Revoked keys stay listed and
        marked, so every approval ever

        accepted can be explained. Needs a human key. See [Manage
        approvers](/guides/manage-approvers).
      operationId: listApprovalIssuers
      responses:
        '200':
          description: The approver keys.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/approval-issuers-list-response.schema'
              examples:
                codeAndGoverned:
                  summary: Real captured response
                  value:
                    issuers:
                      - approverId: manager-charak1987
                        keyId: manager-charak1987-key-1
                        revoked: false
                        source: code
                        publicKeyPem: >
                          -----BEGIN PUBLIC KEY-----

                          MCowBQYDK2VwAyEAVMs/E6N2XEQfEEWlwMg0wRS0L4svbZ0W785aAxUP78M=

                          -----END PUBLIC KEY-----
                      - approverId: manager-priya
                        keyId: manager-priya-key-1
                        publicKeyPem: >
                          -----BEGIN PUBLIC KEY-----

                          MCowBQYDK2VwAyEAEDuWHf+bbRY7J/Mr0RVmAKYHH5CDijTWhdnISXWLD6Y=

                          -----END PUBLIC KEY-----
                        revoked: false
                        addedByChangeId: ba7c5827-5844-4069-94fc-9b438ef08f78
                        addedAt: '2026-09-28T19:05:59.738Z'
                        source: governed
        '401':
          $ref: '#/components/responses/Unauthorized'
        '403':
          description: '`NON_HUMAN_CALLER_DENIED`: this needs a human key.'
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/error.schema'
              examples:
                service:
                  summary: Real captured response, a service credential
                  value:
                    error: >-
                      This action requires a caller credential provisioned as a
                      verified human (credentialHolderType: USER).
                    code: NON_HUMAN_CALLER_DENIED
      x-codeSamples:
        - lang: bash
          label: cURL
          source: |-
            curl https://parmana-api-real.vercel.app/approval-issuers \
              -H "Authorization: Bearer $PARMANA_API_KEY"
        - lang: typescript
          label: TypeScript
          source: |-
            import { ParmanaClient } from "@parmana/sdk";

            const client = new ParmanaClient({
              endpoint: "https://parmana-api-real.vercel.app",
              apiKey: process.env.PARMANA_API_KEY!,
            });

            const approvers = await client.approvers();

            console.log(approvers);
        - lang: python
          label: Python
          source: |-
            import os

            from parmana import ParmanaClient

            client = ParmanaClient(
                endpoint="https://parmana-api-real.vercel.app",
                api_key=os.environ["PARMANA_API_KEY"],
            )

            approvers = client.list_approvers()

            print(approvers)
components:
  schemas:
    approval-issuers-list-response.schema:
      title: Approver Keys List Response
      description: >-
        Response of GET /approval-issuers: keys in code first, then keys added
        through approver changes, revoked ones included.
      type: object
      additionalProperties: false
      required:
        - issuers
      properties:
        issuers:
          type: array
          items:
            $ref: '#/components/schemas/approval-issuer.schema'
    error.schema:
      title: Error Response
      description: >-
        Shared error envelope produced by
        packages/api/src/middleware/error-handler.ts and by every route's inline
        validation checks. error is always a plain human-readable string (never
        a nested object). code is present only when the failure was a
        RuntimeError subclass reaching the centralized error handler
        (VerificationFailedError, ReceiptGenerationError, or an uncategorized
        RuntimeError); it is absent from every inline route-level check
        (businessTransactionId format/required checks) and from
        BusinessTransactionValidationError, PolicyValidationError,
        SignalValidationError, PolicyNotFoundError,
        DuplicateBusinessTransactionError, and the generic 500 fallback. POST
        /policies/validate does NOT use this envelope at all. See its own
        response schema. For the triggering condition and recommended caller
        action behind any specific error/code/status combination, see the Error
        catalog at /api-reference/error-catalog.
      type: object
      additionalProperties: false
      required:
        - error
      properties:
        error:
          type: string
          description: Human-readable error message.
        code:
          type: string
          description: >-
            Stable machine-readable error code. Only present for errors that
            reach the handler as a RuntimeError.
          examples:
            - RUNTIME_ERROR
            - VERIFICATION_FAILED
            - RECEIPT_GENERATION_FAILED
            - POLICY_DENIED
            - CAPABILITY_NOT_ALLOWED
            - RATE_LIMITED
            - AUDIT_UNAVAILABLE
            - SIGNING_UNAVAILABLE
            - CONNECTOR_NOT_REGISTERED
            - EXECUTION_RECORD_INCOMPLETE
            - EXECUTION_INTENT_UNAVAILABLE
            - EXECUTION_INTENT_RESULT_NOT_RECORDED
            - EXECUTION_INTENT_NOT_FOUND
            - EXECUTION_INTENTS_NOT_ENABLED
            - EXECUTION_INTENT_NOT_RESOLVABLE
            - EXECUTION_INTENT_RESOLUTION_INVALID
            - NON_HUMAN_CALLER_DENIED
            - EXECUTION_OUTCOME_UNKNOWN
            - AUTHORIZATION_NO_LONGER_VALID
        executionStatus:
          type: string
          enum:
            - EXECUTION_UNKNOWN
            - NOT_EXECUTED
          description: >-
            RFC-0023 phase 4. EXECUTION_UNKNOWN with EXECUTION_OUTCOME_UNKNOWN:
            the action was released and the call failed, so whether it ran is
            unknown; never reported as failed, and the Execution Intent stays
            ERRORED until a person resolves it. NOT_EXECUTED with
            AUTHORIZATION_NO_LONGER_VALID: the release was refused because a
            business condition or the authority grant it rested on no longer
            held, and nothing was sent.
      examples:
        - error: businessTransactionId must be a valid UUID.
        - error: >-
            Business Transaction 'eed2a972-1bf5-4166-8472-761f76fbf1b2' already
            exists.
        - error: >-
            Execution rejected: Vendor payment rejected because the assessed
            payment risk exceeds the maximum permitted threshold.
          code: RUNTIME_ERROR
    approval-issuer.schema:
      title: Approver Key
      description: >-
        An approver key the server trusts, or trusted, to sign approvals. source
        is code for keys listed in the server's code, and governed for keys
        added through approver changes.
      type: object
      additionalProperties: false
      required:
        - approverId
        - keyId
        - publicKeyPem
        - revoked
        - source
      properties:
        approverId:
          type: string
        keyId:
          type: string
        publicKeyPem:
          type: string
          description: Ed25519 public key, PEM (SPKI).
        revoked:
          type: boolean
          description: 'true: every approval signed with this key is refused.'
        source:
          type: string
          enum:
            - code
            - governed
          description: >-
            code: listed in createApprovalIssuerRegistry.ts, changed only by a
            deploy. governed: added through POST /approval-issuers/changes.
        addedByChangeId:
          type: string
          description: 'governed only: the approved change that added it.'
        addedAt:
          type: string
          format: date-time
          description: governed only.
        revokedByChangeId:
          type: string
          description: 'governed and revoked only: the approved change that revoked it.'
        revokedAt:
          type: string
          format: date-time
          description: governed and revoked only.
  responses:
    Unauthorized:
      description: >-
        The `Authorization` header is missing, is not a bearer key, or names a
        key the server does not know. Nothing ran. Send a valid key.
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/error.schema'
          examples:
            authRequired:
              summary: Real captured response, missing or invalid Authorization header
              value:
                error: authentication required
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      x-default: 2VfYWCzt_cBAPK-8uufX6ordfY2JuQhFPsohuEumKME
      description: >
        Caller API key issued by scripts/generate-api-key.ts. Sent as
        Authorization: Bearer <key>. Verified against a stored SHA-256 hash in
        constant time by packages/api/src/auth/StaticKeyAuthenticator.ts.
        Required on every route not listed as exempt in this document's
        top-level description. See /api-reference/authentication.

````

This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.