Skip to main content
Constructs a fully-formed, internally-consistent BusinessTransaction from the fields a caller actually decides, deriving every field the server’s own BusinessTransactionValidator checks for cross-consistency (packages/runtime/src/validators/BusinessTransactionValidator.ts) so a caller can never build a request that fails one of those checks by mistake:
  • metadata.business_transaction_id always equals business_transaction_id
  • authorization.authority_id always equals authority.authority_id
  • intent.authorization_id always equals authorization.authorization_id
Hand-building a BusinessTransaction by constructing all five nested dataclasses and keeping three id pairs in sync by hand is exactly the class of mistake that produced every “X must match Y” 400 response documented in END-TO-END-FLOW.md (repo root) — this function exists so that mistake is structurally impossible when going through the SDK, not merely documented as something to be careful about. Not auto-generated: unlike everything in parmana.models, this is a hand-maintained convenience layer, not a 1:1 mirror of a TypeScript domain type — python/scripts/generate_models.ts never touches this file.

​
create_business_transaction

Builds a BusinessTransaction with every cross-referenced id derived and kept consistent automatically. business_transaction_id defaults to a fresh uuid4() if omitted — a caller providing one explicitly is responsible for it being unique per attempt, since it doubles as the server’s own idempotency key (see docs/site/guides/end-to-end-paytm-flow.mdx, “businessTransactionId is an idempotency key”). authority_type defaults to SERVICE — the correct value for an autonomous agent. There is no “AGENT” value; it does not exist server-side. principal_id must match one of the caller API key’s own allowed_principal_ids server-side, or the request is rejected before policy ever runs — see GET /callers/me.