Skip to main content
Each sub-API is a small class over a shared Transport, one file per concern under typescript/src/client/. Every one of them documents, in its own header comment, what it explicitly does not do — a pattern worth reading literally, since it reflects real separation of concerns in this codebase, not just style.

HealthApi

health() → GET /health

ExecutionApi

health(), execute(transaction) → POST /execute

VerificationApi

verify(id) → GET /verification/:id

ReplayApi

replay(id) → POST /replay

ReceiptApi

generate(id) → POST /receipt

TransactionApi

get(id), list(page, pageSize) → GET /transactions[/:id]

TrustRecordApi

get(id) → GET /trust-records/:id

PolicyApi

validate(policy) → POST /policies/validate

​
ExecutionApi

typescript/src/client/ExecutionApi.ts. Duplicates health() (also on HealthApi) alongside execute(): 
class ExecutionApi {
  health(): Promise<unknown>;
  execute(transaction: BusinessTransaction): Promise<ExecutionTrustRecord>;
}

​
VerificationApi

typescript/src/client/VerificationApi.ts. Exactly one method, and it’s a read, not a trigger: 
class VerificationApi {
  verify(businessTransactionId: string): Promise<Verification>;
  // sends GET /verification/${businessTransactionId}
}

​
ReplayApi

typescript/src/client/ReplayApi.ts: 
class ReplayApi {
  replay(businessTransactionId: string): Promise<ReplayResult>;
  // sends POST /replay
}
See REST API → Replay for what this endpoint actually checks (a trust-record hash, not a re-run of policy evaluation).

​
ReceiptApi

typescript/src/client/ReceiptApi.ts. Its header comment explicitly disclaims verification, execution, and replay — and true to that, it also has no method for reading back a previously generated Receipt: 
class ReceiptApi {
  generate(businessTransactionId: string): Promise<Receipt>;
  // sends POST /receipt — there is no get()/latest()
}

​
TransactionApi

typescript/src/client/TransactionApi.ts: 
class TransactionApi {
  get(businessTransactionId: string): Promise<BusinessTransaction>;
  list(page?: number, pageSize?: number): Promise<BusinessTransaction[]>;
  // list() builds its own query string: /transactions?page=${page}&pageSize=${pageSize}
}

​
TrustRecordApi

typescript/src/client/TrustRecordApi.ts: 
class TrustRecordApi {
  get(businessTransactionId: string): Promise<ExecutionTrustRecord>;
}

​
PolicyApi

typescript/src/client/PolicyApi.ts. Defines its own PolicyValidationResult interface locally rather than importing one from models/: 
interface PolicyValidationResult {
  readonly valid: boolean;
  readonly errors: readonly string[];
}

class PolicyApi {
  validate(policy: Policy): Promise<PolicyValidationResult>;
  // Policy is imported from @parmana/policy, not typescript/src/models
}
PolicyApi’s export is commented out of typescript/src/index.ts (// export { PolicyApi } from "./client/PolicyApi.js";), so it’s not part of the package’s public surface for standalone use — construct it yourself from typescript/src/client/PolicyApi.ts if you need it outside of ParmanaClient.validatePolicy().

​
HealthApi

typescript/src/client/HealthApi.ts: 
interface HealthStatus {
  readonly status: string;
  readonly version?: string;
  readonly timestamp?: string;
}

class HealthApi {
  health(): Promise<HealthStatus>;
}
HealthStatus models optional version and timestamp fields that the real GET /health handler never returns — see REST API → System for what the server actually sends back ({ "status": "UP" } only).

ParmanaClient

The facade composing all of these.

Models

Request/response types used above.

Errors

What each of these throws on failure — and what they don’t.

REST API

The HTTP surface these classes wrap.