Execute a Business Transaction
Runs the complete Execution Trust pipeline synchronously: accepts the Business Transaction, executes it through the Runtime, verifies the resulting Execution Trust Record, generates a Receipt, then returns the complete, updated Execution Trust Record. businessTransactionId must be a valid UUID (v1-v5) or the request fails before any persistence with a 400. See BusinessTransactionMapper.fromRequest and isValidBusinessTransactionId in packages/api/src/routes/execute.ts. The mapper reconstructs the transaction field by field, so status and createdAt supplied by the client are always ignored (Parmana assigns RECEIVED and the current time), and any top-level field not in the request schema is silently dropped. POST /transactions applies the identical UUID check and mapper. See that endpoint below.
If Policy evaluation REJECTs the transaction, this endpoint currently responds 500 with a RUNTIME_ERROR-coded error envelope naming the rejection reason. See the 500 response below and the executeRejected example. This is real, observed behavior, not a designed contract; it is documented here because the spec must describe the API as implemented.
hubspot:deal-update and hubspot:deal-fetch are the real, currently-registered capabilities reachable through this same endpoint by this capability-based routing mechanism today. Registration is conditional on HUBSPOT_PRIVATE_APP_TOKEN being configured; if it is not, the connector is never registered and this action falls into the “no Connector registered” case documented under 500 below. See packages/api/tests/integration/hubspot-deal-update.integration.test.ts for the executable, real-request proof of the hubspot flow.
payments:execute (vendor-payment), shown in the vendor-payment-flow example below, was removed from the repository entirely — see docs/VERIFICATION-GAPS.md G-27 in the source repo. That example is a real request/response pair captured before the removal; resubmitting it against a current server no longer produces the shown APPROVED result; it falls into the “no Connector registered” case instead, since no connector — production or test — registers payments:execute any longer. It is retained here as a real, historical illustration of the response shape, not as a currently-runnable example. The vendor-payment/2.0.0 policy file itself is unaffected and still loads (see PolicyValidate below); only the connector that would have executed against it is gone.
Authorizations
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 except GET /health. See /api-reference/authentication.
Body
Request payload for POST /execute and POST /transactions. status and createdAt are assigned by Parmana and must not be supplied by the client. Validation performed identically by both endpoints (each has its own inline businessTransactionId UUID check, then shares BusinessTransactionMapper.fromRequest and BusinessTransactionValidator): metadata.businessTransactionId must equal businessTransactionId; authorization.authorityId must equal authority.authorityId; intent.authorizationId must equal authorization.authorizationId; policy.name, policy.version, and intent.action must each be non-empty. No other structural validation is performed: authority, authorization, intent, policy, and signals objects are otherwise passed through as supplied, including any additional properties.
Unique Business Transaction identifier. Must be a valid UUID on both POST /execute and POST /transactions (rejected with 400 otherwise).
Immutable Business Transaction metadata supplied by the calling application. Not evaluated by Policy. businessTransactionId is the only required field; it must match the top-level businessTransactionId. Parmana rejects a mismatch with a 400.
Entity empowered to authorize execution within a trust domain. Immutable once issued.
Immutable trust artifact proving that an Authority granted approval for an intended execution.
Immutable declaration of the action an Authority intends to be executed under an Authorization.
Exact Policy to evaluate. The client explicitly supplies name, version, and schemaVersion; Parmana does not automatically discover or select a policy. If no matching policy file exists at policies/{name}/{version}/policy.json, the request fails with a 404 (policyId/policyVersion on POST /policies/validate) or a RUNTIME_ERROR (name/version elsewhere, from PolicyNotFoundError not otherwise mapped by the shared error handler in every route, see the error envelope note).
Opaque runtime facts evaluated by the resolved Policy's rules. Parmana assigns no business meaning to these values and does not statically validate them beyond the Policy's own signalsSchema declaration (see policies/{name}/{version}/policy.json). Scaled integers, not floats, for numeric signals such as amounts (house convention across every reference policy).
Response
Execution Trust pipeline completed. The Execution Trust Record reflects whatever the Decision outcome was. This status code does not by itself mean the payment was approved.
Canonical immutable record representing everything Parmana knows about a Business Transaction: the authoritative source for replay, verification, audit, and receipt generation. One Execution Trust Record exists per Business Transaction. overrides, executions, verifications, and receipts are append-only: existing entries are never modified or removed.
Unique Execution Trust Record identifier.
Business Transaction identifier.
Canonical immutable business context accepted by Parmana for execution: Authority -> Authorization -> Intent -> Business Transaction -> Policy. Every Business Transaction produces exactly one Decision, one Execution, and one Execution Trust Record.
Override history. Append-only; empty on every transaction in this repository today (no route creates an Override).
Execution history. Append-only.
Verification history. Append-only.
Receipt history. Append-only.
Canonical hash of the Execution Trust Record, computed over its canonical serialized form.
Cryptographic signature over the canonical Execution Trust Record, proving it was produced by Parmana and has not been modified since signing.
UTC timestamp when the Execution Trust Record was first created.
UTC timestamp when the Execution Trust Record was last extended with a new immutable artifact.