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

# Replay an Execution Trust Record

> Re-verifies the stored signature on the Execution Trust Record for businessTransactionId and returns its hash alongside the verification result. Does not re-run Policy evaluation or re-execute anything. See ExecutionTrustApplication.replay. When businessTransactionId does not correspond to any Execution Trust Record, this throws VerificationFailedError (the same not-found error used by POST /verify), which the shared error handler maps to a 404 naming the missing resource. See the 404 response and its notFound example.




## OpenAPI

````yaml /openapi.bundled.yaml post /replay
openapi: 3.1.0
info:
  title: Parmana API
  version: 1.0.0
  description: >
    Parmana is an Execution Trust Infrastructure that ensures there is no gap
    between what humans decide and what AI systems do. The API enables creation,
    execution, verification, replay, and auditing of Business Transactions
    through cryptographically verifiable Execution Trust Records.


    **Every route requires a caller bearer key, except GET /health.** Send
    `Authorization: Bearer <key>` on every other request. Keys are issued by
    `scripts/generate-api-key.ts` and configured server-side via
    `PARMANA_API_KEYS`; only a hash of each key is ever held by the server,
    verified in constant time. A missing or invalid credential returns 401
    before a Business Transaction is even constructed, independent of Policy
    evaluation and gateway attestation, see
    `packages/api/src/middleware/caller-auth.ts` and
    [Authentication](/api-reference/authentication). Local development may set
    `PARMANA_AUTH_DISABLED=true` to skip this middleware entirely; that flag
    must never be set in a real deployment.
  contact:
    name: Parmana
    email: support@parmana.ai
  license:
    name: Apache-2.0
    identifier: Apache-2.0
servers:
  - 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: System
    description: Operational endpoints
paths:
  /replay:
    post:
      tags:
        - Replay
      summary: Replay an Execution Trust Record
      description: >
        Re-verifies the stored signature on the Execution Trust Record for
        businessTransactionId and returns its hash alongside the verification
        result. Does not re-run Policy evaluation or re-execute anything. See
        ExecutionTrustApplication.replay. When businessTransactionId does not
        correspond to any Execution Trust Record, this throws
        VerificationFailedError (the same not-found error used by POST /verify),
        which the shared error handler maps to a 404 naming the missing
        resource. See the 404 response and its notFound example.
      operationId: replayTransaction
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/replay-request.schema'
            examples:
              vendor-payment-flow:
                summary: Real captured request
                value:
                  businessTransactionId: 44b34a79-e0f2-49d7-a48e-e52fff88182e
      responses:
        '200':
          description: Replay completed.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/replay-response.schema'
              examples:
                vendor-payment-flow:
                  summary: Real captured response
                  value:
                    businessTransactionId: 44b34a79-e0f2-49d7-a48e-e52fff88182e
                    trustRecordHash: >-
                      e20a8861864f1a0a6c5fe00e64abca04de18a7d165a82ef9d7beb458c2096b3f
                    verified: true
        '400':
          description: businessTransactionId missing.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/error.schema'
              examples:
                missingField:
                  summary: Real captured response
                  value:
                    error: businessTransactionId is required.
        '401':
          $ref: '#/components/responses/Unauthorized'
        '404':
          description: >-
            businessTransactionId does not correspond to any Execution Trust
            Record (VerificationFailedError, the same not-found error used by
            POST /verify).
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/error.schema'
              examples:
                notFound:
                  summary: Real captured response
                  value:
                    error: Execution Trust Record not found.
                    code: VERIFICATION_FAILED
components:
  schemas:
    replay-request.schema:
      $schema: https://json-schema.org/draft/2020-12/schema
      $id: https://schemas.parmana.ai/requests/replay-request.schema.json
      title: Replay Request
      description: >-
        Request payload for POST /replay. businessTransactionId is required
        (rejected with a 400 if missing or empty), unlike POST /verify and POST
        /receipt, this route does not additionally validate UUID format.
      type: object
      additionalProperties: true
      required:
        - businessTransactionId
      properties:
        businessTransactionId:
          type: string
          description: Business Transaction to replay.
      examples:
        - businessTransactionId: eed2a972-1bf5-4166-8472-761f76fbf1b2
    replay-response.schema:
      $schema: https://json-schema.org/draft/2020-12/schema
      $id: https://schemas.parmana.ai/responses/replay-response.schema.json
      title: Replay Response
      description: >-
        Response returned by POST /replay. A deliberately small shape distinct
        from the Execution Trust Record it replays: it re-verifies the record's
        stored signature via VerificationCrypto and reports only whether that
        succeeded, alongside the hash it checked.
      type: object
      additionalProperties: false
      required:
        - businessTransactionId
        - trustRecordHash
        - verified
      properties:
        businessTransactionId:
          type: string
          description: Business Transaction that was replayed.
        trustRecordHash:
          type: string
          description: Hash of the Execution Trust Record that was replayed.
        verified:
          type: boolean
          description: >-
            Whether the Execution Trust Record's stored signature verified
            successfully.
      examples:
        - businessTransactionId: eed2a972-1bf5-4166-8472-761f76fbf1b2
          trustRecordHash: 989aef83d595202ec02bb338ac00461abec0541098ea065f965b5cde342d3b25
          verified: true
    error.schema:
      $schema: https://json-schema.org/draft/2020-12/schema
      $id: https://schemas.parmana.ai/common/error.schema.json
      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
      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
  responses:
    Unauthorized:
      description: >-
        Missing or invalid caller credential (StaticKeyAuthenticator returned no
        identity). Real captured response,
        packages/api/src/middleware/caller-auth.ts.
      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
      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 except GET /health. See
        /api-reference/authentication.

````