The engine and its API run at the venue and act only as the venue’s party. Register keepers, price sources and investors act on their own systems; see Who runs what.
The engine’s REST API under /v1: a deployment’s instruments, holders, orders, settlements, distributions, controls, reconciliation, reports and events. The engine’s contract tests hold this document to the routes it serves, their access rules and the engine’s types. The base URL is your deployment’s engine; these pages write it as https://engine.example.com. Each route’s page shows the request in curl, with your bearer as $TOKEN, then the same call through a client OpenAPI Generator makes from this document, in TypeScript, Python and Java (Build a client). A caller signs in with a bearer JWT from your identity provider, whose roles claim names its roles; a service client also signs each request (X-Signature-Key and the headers beside it, Request signing). These routes need no sign-in: GET /v1/tenants/{tenantId}, GET /v1/health, GET /v1/openapi.json. The roles are grouped by who holds them: the venue’s own staff, the venue’s own systems, and outside parties working with the venue (Roles and access).

Conventions

Pages, writes, four eyes, rate limits, decimals, times and identifiers: one example each.

Resources and business areas

Where each record lives, and which business area each group covers.

Values

Every set of values a field takes, and what each value means.

Problems

Every refusal: its code, its status, what it means and how to recover.

Roles and access

The roles, and what each may read, write and approve.

Webhook events

Every event the engine posts to a webhook, and its payload.

Operation results

What each write that moves units or cash answers in its operation’s result.

How the API works

Sign-in, signed requests and retries, worked through with curl.

Build a client

Generate a client for the API in your own language.

Downloads

The OpenAPI document and the DARs, from one release.