> ## 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. # Verify a signed caller-authentication audit event > Verifies a signed caller-authentication audit event's signature, the same unauthenticated, third-party-verifiable capability as POST /refusal/verify, over the durable caller_audit_events audit trail instead of Refusal Records. No database lookup involved, pure signature-over-bytes verification against the event and signature supplied in the request body. Only production (Supabase) audit sinks sign; in-memory test sinks never produce a genuinely valid signature for this route to confirm. ## OpenAPI ````yaml /openapi.bundled.yaml post /audit/verify 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 the liveness/readiness probes and documentation/verification routes that must be reachable with no credential: GET /health, GET /ready, GET /openapi.yaml, GET /documentation, GET /reference, POST /refusal/verify, POST /audit/verify, GET /keys/{keyId}, and GET /.well-known/jwks.json. Send `Authorization: Bearer ` 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 Systems email: founder@parmanasystems.com license: name: Proprietary, source-available for evaluation only, see LICENSE url: https://github.com/pavancharak/AgentLabsBuildathon/blob/main/LICENSE 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: Policy Governance description: Maker-checker proposal, listing, approval, and rejection of policy changes - name: Refusal Records description: >- Durable, signed evidence that a policy decision rejected a transaction (RFC-0021) - name: Audit description: >- Signed caller-authentication audit events, independently third-party-verifiable - name: System description: Operational endpoints paths: /audit/verify: post: tags: - Audit summary: Verify a signed caller-authentication audit event description: > Verifies a signed caller-authentication audit event's signature, the same unauthenticated, third-party-verifiable capability as POST /refusal/verify, over the durable caller_audit_events audit trail instead of Refusal Records. No database lookup involved, pure signature-over-bytes verification against the event and signature supplied in the request body. Only production (Supabase) audit sinks sign; in-memory test sinks never produce a genuinely valid signature for this route to confirm. operationId: verifyAuditEvent requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/audit-verify-request.schema' responses: '200': description: >- Verification completed. A 200 does not by itself mean the signature verified, see the valid field. content: application/json: schema: $ref: '#/components/schemas/verify-result-response.schema' examples: invalid: summary: >- Real captured response (this environment's in-memory audit sink never signs, so no genuinely valid signature is capturable here) value: valid: false '400': description: >- Request body is not a structurally plausible { event, signature } pair. content: application/json: schema: $ref: '#/components/schemas/error.schema' examples: malformed: summary: Real captured response value: error: >- Request body must be { event, signature } (event: type, occurredAt, route; signature: algorithm, keyId, value required). security: [] components: schemas: audit-verify-request.schema: title: Audit Verify Request description: >- Request body for POST /audit/verify: the signed caller-authentication audit event and its stored signature, not a lookup by ID. Checked structurally on the server before signature verification runs. Verification operates on canonical bytes and the signature alone, never on event.type. type: object additionalProperties: false required: - event - signature properties: event: type: object description: >- The caller-authentication audit event as stored. Only type, occurredAt, and route are structurally required; the event may carry further fields depending on what produced it. additionalProperties: true required: - type - occurredAt - route properties: type: type: string occurredAt: type: string format: date-time route: type: string signature: type: object description: >- The signature stored alongside the event. Only production (Supabase) audit sinks sign; in-memory test sinks never produce a genuine one of these. additionalProperties: true required: - algorithm - keyId - value properties: algorithm: type: string examples: - ed25519 keyId: type: string value: type: string description: Base64-encoded signature value. examples: - event: type: caller_authenticated occurredAt: '2026-09-15T03:00:00.000Z' route: /version signature: algorithm: ed25519 keyId: default value: >- AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== verify-result-response.schema: title: Verify Result Response description: >- Response shared by POST /refusal/verify and POST /audit/verify: a bare signature-validity result, no wrapper, no partial-failure detail. Both routes verify a signature over bytes with no database lookup, so there is nothing more specific to report than valid or not. type: object additionalProperties: false required: - valid properties: valid: type: boolean description: >- Whether the signature verifies against Parmana's public key for the stated algorithm and key ID. examples: - valid: true - valid: false 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 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 securitySchemes: bearerAuth: type: http scheme: bearer description: > Caller API key issued by scripts/generate-api-key.ts. Sent as Authorization: Bearer . 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. ````