Kaia Developers
The keyed industry API for regulated work.
One API across the four launch industries — Legal, Accounts Payable, Claims, and Oil & Gas. Keys are minted inside the product by your organization. Every decision the engine returns carries its provenance: the classification and its axes, the confidence, the regulated floors it hit, and the receipts behind every figure.
How it works
1 · Mint a key
Keys are minted inside the product by your organization — Settings → Integrations → Developer access. Shown once at issuance; only its digest is stored. Scopes: intake:write, intake:read, runs:read.
2 · Submit documents or batches
Create a document, PUT the bytes to the presigned URL, confirm. Batches resolve their matter once and members inherit it — targeting is always explicit, never adopted implicitly.
3 · Classification with provenance
The engine classifies and records how it decided: the classification and its axes exactly as stored, the confidence, the model that served it, and the floors the decision hit.
4 · Signed webhooks
Subscribe to signed event deliveries — document classified or failed, batch completed, run advanced, awaiting a human, completed, correction applied. Payloads carry identifiers and state; the decision substance stays behind your key.
5 · Read the results
Poll run state cheaply, then read the full result: the decision summary, the regulated floors (held or released), the per-figure receipts, and the transition trace.
Endpoint reference
The complete published surface. Authenticate every request with Authorization: Bearer kaia_live_… — a per-organization key whose scopes gate what it may call.
| Endpoint | Scope | What it does |
|---|---|---|
POST/api/v1/documents | intake:write | Create a document and receive a presigned upload URL (15-minute expiry). |
GET/api/v1/documents | intake:read | List documents within a matter, cursor-paged. A list is always matter-scoped. |
GET/api/v1/documents/{documentId} | intake:read | Document processing status — the polling contract. |
POST/api/v1/documents/{documentId}/confirm | intake:write | Confirm the upload; processing chains automatically. Idempotent. |
POST/api/v1/batches | intake:write | Create a batch. The batch resolves its matter once; members inherit it. |
GET/api/v1/batches/{batchId} | intake:read | Batch progress — processed, failed, remaining, percent complete. |
GET/api/v1/runs | runs:read | List runs, cursor-paged — filter by vertical, matter, state, or live. |
GET/api/v1/runs/{runId} | runs:read | Run state — stage, mode, awaiting-human, and the regulated-floor force-stop. |
GET/api/v1/runs/{runId}/result | runs:read | The run result — decision summary, classification with axes, floors, per-figure receipts, and the transition trace. |
GET/api/v1/matters | intake:read | List targetable matters for a vertical. Targeting is always explicit. |
Errors: every error is an RFC 9457 problem document (application/problem+json) with a stable machine code — the same twelve codes across the whole surface.
Webhook signing: every delivery carries Kaia-Signature: t=<unix>,v1=<hex> — an HMAC-SHA256 over the timestamp and raw body together, verified in constant time with a 300-second replay window; delivery is at-least-once with bounded retry, and the stable event id is your idempotency key.
Rate limit: 600 requests per minute per key, honoring Retry-After.
Runs are read-only: the API reads what the engine decided — it never advances, answers, or overrides a run. Those are actions people take in the product, where they are recorded and attributed.
OpenAPI 3.1
The machine-readable contract this page is written from — every endpoint, schema, problem code, and webhook definition above, served live.
https://portal.kaiaai.ai/api/v1/openapi.jsonMCP tool manifest
A capability listing derived mechanically from the same OpenAPI contract — every operation appears as exactly one tool, so the two can never drift. It is a manifest, not a running MCP server: what is not implemented today (the MCP transport itself, the agent discovery card) is declared inside the manifest's own notImplemented field.
Three mechanisms, never conflated
Work reaches Kaia three distinct ways. Each is named, each is documented on its own terms, and a capability in one never implies a capability in another.
Intake modes
How work enters inside the product — single items, batches, and where a vertical supports it, case targeting. A product behavior, configured per vertical.
The keyed API
This page: programmatic submission and read-back under a key your organization minted. Read-only over runs — the API never drives the orchestration.
Connectors
Integrations with the systems you already run, configured per engagement. A connector is a separate mechanism — never implied by an API capability, and never the same thing as an intake mode.
Legal
What the API accepts today
Documents and batches, always bound to a matter. Targeting is explicit on every submission — an existing matter id or a new matter, never adopted implicitly. A Legal batch groups documents under one matter; it never changes how each document is processed.
95.7% privilege-detection accuracy — measured internally on 810 frozen documents, published as-is. Method and full results →
Accounts Payable
What the API accepts today
Invoice documents — invoices only, by design. Purchase orders and receipts are not API payloads: they reach invoice matching through ERP connector setup, configured per engagement — the connector mechanism, not this API. A batch is an invoice load worked as one payment cycle.
92.75% exact extraction accuracy on 1,200 held-out invoices · 100% sanctions-screening recall on the same set — measured internally. Method and full results →
Claims
What the API accepts today
Single claim documents via the API, plus batch submission — a Claims batch is adjudicated as one governed run with per-claim results. Status reads return plain JSON acknowledgments of document and batch state.
99.66% fraud-signal recall · 96.05% overall exact accuracy across all decision classes on the same 860 held-out records — measured internally. Method and full results →
Oil & Gas
What the API accepts today
Single and batch submissions under one filing target — each item processed as its own case — plus four vendor-neutral structured data classes, submitted as JSON documents against schemas published in the OpenAPI contract. Every record carries ingestion provenance: the source system and the as-of date of the data.
erp-cost— capital and operating expenditure with downtime, by period.subsurface-decline— production-rate-vs-time observations, fitted decline parameters, and estimated ultimate recovery.telemetry— pressure, flow, and flare streams with downtime logs.operating-plans— operating-plan entries and prior bookings by horizon.
No accuracy score in this section, deliberately. The reserves lane is a deterministic engineering engine, not a trained classifier — every figure it produces carries the calculation that produced it, reproducible from stored evidence. When results are published for Oil & Gas, they will be engineering-verification results. The standard, on the record →
Design partners build against this same surface.
The keys, the contract, and the numbers on this page are the ones a design partner works with — on your documents, held to the published methodology.
Every number on this page carries its measurement status and traces to a stored measured artifact behind the benchmarks page; industries without one carry no score.