Build on InsureFlow.
One API for insurance operations, aligned to open standards, with the domain modelled for you: parties, products, coverage, claims, premium, and receipts. Ask for access and we issue a key against a tenant.
Authenticate, then make the first call.
Exchange your client credentials for a bearer token, then call the API, in the language you build in. Your gateway host is issued with your credentials, so it is read from the environment here rather than printed. Every resource follows the same shape.
# 1. Exchange client credentials for a bearer token
curl -X POST "$TRISILVA_AUTH_URL/oauth/token" \
-d grant_type=client_credentials \
-d client_id="$TRISILVA_CLIENT_ID" \
-d client_secret="$TRISILVA_CLIENT_SECRET" \
-d scope="$TRISILVA_SCOPE"
# -> { "access_token": "...", "token_type": "Bearer", "expires_in": 3600 }
# 2. Call the API with the token
curl "$TRISILVA_API_URL/v1/coverages" \
-H "Authorization: Bearer $ACCESS_TOKEN"
# -> a cursor-paginated list of coverages, JSON, open-standard fields
// 1. Exchange client credentials for a bearer token
const auth = await fetch(`${process.env.TRISILVA_AUTH_URL}/oauth/token`, {
method: "POST",
headers: { "Content-Type": "application/x-www-form-urlencoded" },
body: new URLSearchParams({
grant_type: "client_credentials",
client_id: process.env.TRISILVA_CLIENT_ID!,
client_secret: process.env.TRISILVA_CLIENT_SECRET!,
scope: process.env.TRISILVA_SCOPE!,
}),
});
const { access_token } = await auth.json();
// 2. Call the API with the token
const coverages = await fetch(`${process.env.TRISILVA_API_URL}/v1/coverages`, {
headers: { Authorization: `Bearer ${access_token}` },
}).then((r) => r.json());
// -> a cursor-paginated list of coverages, JSON, open-standard fields
import os, requests
# 1. Exchange client credentials for a bearer token
auth = requests.post(
f"{os.environ['TRISILVA_AUTH_URL']}/oauth/token",
data={
"grant_type": "client_credentials",
"client_id": os.environ["TRISILVA_CLIENT_ID"],
"client_secret": os.environ["TRISILVA_CLIENT_SECRET"],
"scope": os.environ["TRISILVA_SCOPE"],
},
).json()
access_token = auth["access_token"]
# 2. Call the API with the token
coverages = requests.get(
f"{os.environ['TRISILVA_API_URL']}/v1/coverages",
headers={"Authorization": f"Bearer {access_token}"},
).json()
# -> a cursor-paginated list of coverages, JSON, open-standard fields
Authentication is OAuth 2.0 client credentials, and the token is a bearer token on every subsequent call. Scopes are granted to your tenant rather than fixed for everyone, so the ones your credential carries are issued with it. How tenancy and scopes work.
The surface today, and what is still in build.
The HTTP API is running and the standard behind it is published open. The tooling around them derives from one contract rather than being written by hand, which is what the second group below is being generated from.
The HTTP API
Channel, product and coverage are running services. The platform documentation covers each one: what it owns, what it validates, and where it sits across the two deployment planes.
Platform architecture →The open standard
The vocabulary and the API design the services speak at their boundaries: parties, products, coverage, claims, premium and receipts. Twelve modules, published open, with the Vietnam market profile beside them.
Read the standard →API reference
A machine-readable contract for the synchronous API, so you generate a client instead of writing one. This is the piece we most want to ship, because the SDKs and the CLI below all wait on it.
Event surface
Coverage already publishes domain events internally. What is missing is the catalogue that describes them and a subscription path you can use from outside the platform.
Webhooks
Signed HTTP callbacks to deliver those events to your endpoint, retried on failure until they are acknowledged.
SDKs
Typed client libraries that wrap authentication, pagination, and the resource model, so you write insurance logic rather than HTTP plumbing.
MCP endpoints
Model Context Protocol endpoints exposing the same operations to AI agents as typed tools, so an agent reads and acts on insurance data directly.
The design →CLI
A command-line client for scripting, inspection, and one-off calls against your tenant, without writing a client first.
The design →All six derive from one artefact rather than being built beside each other, which is why they behave consistently and why a change to the contract reaches every one of them. How the integration surface is put together.
What holds while you build on it.
The parts an integration depends on long after the first call: a versioning rule that tells you when something moves, one error shape, and one retry rule.
A published versioning rule
01The standard declares what counts as a breaking change before one arrives, and breaking corrections are held and released together, so you absorb one change instead of three.
One error shape
02Errors come back as RFC 7807 problem documents, the same shape on every endpoint, so a client handles failure once rather than per resource.
Idempotent writes
03Every write carries an Idempotency-Key header and the platform honours it for seven days, so a retried request is never applied twice, however your client handles a timeout.
Authentication, the error model, cursor pagination and idempotency are settled in the standard's API conventions rather than left to each integration, and the platform implements them rather than restating them. The machine-readable JSON Schema for those definitions is derived from that normative prose rather than authored beside it, so the two cannot drift apart. How conformance is graded.
See the three-tier standards stack →The surface an agent can build on, not just a person.
Neither of these is built. They are stated here because they are design commitments the API contract is being shaped around, not features you can call this week.
MCP endpoints
Model Context ProtocolEvery operation the API exposes will also be a Model Context Protocol tool with a typed input and output. An AI agent connects to the MCP endpoint and reads policies, triages claims, or reconciles a period directly, working against the same authenticated, audited surface a human integrator uses, rather than screen-scraping or prompt-to-form glue. The endpoint waits on the OpenAPI document, because the tool definitions are generated from the same contract.
CLI
Command lineThe command-line client will turn the same surface into something you can script and pipe. Inspect a coverage, replay an event, or wire a call into a build step. It is the fast path for work that does not need an SDK, and it waits on the same contract the SDKs do.
How access works today.
Access is granted rather than self-served. That is where we are today, and it is not where this is going.
Credentials
01Ask for developer access and we issue a client ID and secret against a tenant. Authentication is OAuth 2.0 client credentials, and the scopes a credential carries follow from what its tenant is entitled to do.
Self-serve sandbox
02A sandbox seeded with representative parties, policies and claims, isolated from any live tenant, so you confirm an integration before asking for production credentials. Not built yet. Until it is, ask us and we will work out a test tenant with you.
Rate model
03Limits are set with your tenant when you go live, against what your integration actually does, rather than applied as one number to everyone.
Start building.
Read what is built, then ask for a key. We would rather you know the gaps before you start than find them afterwards.
The integration surface: how you build against it · Service state: the status page · the standards behind the surface