Developers

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.

Quickstart

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.

quickstart
# 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.

What you get

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.

Live now
REST over HTTP

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
OPIN, MPL 2.0

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
In build
OpenAPI 3.1

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.

AsyncAPI 3.1

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.

Signed callbacks

Webhooks

Signed HTTP callbacks to deliver those events to your endpoint, retried on failure until they are acknowledged.

Typed clients

SDKs

Typed client libraries that wrap authentication, pagination, and the resource model, so you write insurance logic rather than HTTP plumbing.

Model Context Protocol

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
Command line

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.

The contract

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

01

The 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

02

Errors 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

03

Every 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
Built AI-first

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 Protocol

Every 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 line

The 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.

Access

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

01

Ask 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

02

A 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

03

Limits 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.

Singapore · Vietnam · Indonesia · Philippines