Vannarho RaaS — API User Guide¶
The detailed, integrator-facing guide to the Governed Risk Results Platform API.
Document Version: 1.0.0
Last Updated: 2026-06-11
Facts in EAA regions are generated from current state
Prose in this guide is hand-written. Counts and catalogs inside EAA regions (route catalogs, schema breadth) are rendered live from the platform's current EAA evidence and CI-checked for freshness. Where the pinned evidence is narrower than the full typed contract surface, the guide says so.
Who This Is For¶
This guide is for engineers integrating systems with Vannarho RaaS: bringing market data, trades, and portfolios into the platform; configuring and governing runs; executing regulator-grade analytics; and consuming governed results and evidence — all through typed APIs.
If you want the platform story and architecture, start with the Platform Overview. This guide is the API reference layer beneath it.
The Integration Model In One Picture¶
flowchart LR
A[Upload artifacts] --> B[Create submission]
B --> C[Translation to canonical objects]
C --> D[Readiness evaluation]
D --> E[Approval / waivers]
E --> F[Governed run request]
F --> G[Execution + evidence]
G --> H[Results / insight cases]
Three principles shape every endpoint:
- Headless & contract-first. Everything the Workbench does, your systems can do through the same typed OpenAPI surface. There is no privileged backdoor.
- Intake-first. Data enters as governed submissions that are validated and translated into canonical objects — not via unvalidated per-entity writes.
- Governed by default. Readiness, approval, evidence, and lineage are part of the path, not optional extras.
How Big Is The Surface¶
The platform's analytical truth that these APIs read and write spans
857
governed tables and
26619
fields, behind
53
governed runtime boundaries.
How To Use This Guide¶
| Chapter | What it covers |
|---|---|
| Getting Started | The end-to-end happy path, first call to first result |
| Authentication & Gateway | How requests are authenticated and routed |
| Intake APIs | Submitting trades, market data, reference, runtime config |
| Submission & Translation | Submissions, translation reports, canonical objects |
| Config Doctor | Readiness cases, validation, repair, evidence |
| Governance | Readiness evaluations, approvals, waivers |
| Execution & Runs | Run requests, dispatch, run-from-reference-pack |
| Results, Evidence & Insight Cases | Reading governed facts and explainability |
| Reference Packs & Publication | Reference scenarios and input/runtime publication |
| Errors & Long-Running Operations | Operation handles, polling, error model |
| API Surface & Evidence | The full surface and how it maps to maturity |
A Note On Maturity¶
Some endpoints are wired to running backends today; others are typed contracts whose backends are planned. This guide marks each group, and the authoritative classification lives in the platform's maturity register. A typed contract with no wired backend is a design asset — it is not a delivered API.