The API has two axes. The collections are where records live: a record with an id of its own has a home at the top of /v1, and its parent is a filter on that collection, as in GET /v1/subscriptions?instrumentId=FUND. The business areas are the reference’s groups, in the order an asset’s life runs; each gathers the operations of one part of that life, whichever collections they use. What exists once for each parent lives under it: an instrument’s policy, register and prices sit under /v1/instruments/{instrumentId}, and a holder’s admissions, statements and portfolio under /v1/holders/{holderId}. The lists below the table name them all. An answer the engine works out is a noun too, read with GET, and it changes nothing: the reconciliation verdict (GET /v1/reconciliation-verdict), the distribution calendar (GET /v1/distribution-calendar) and open orders (GET /v1/open-orders). An action is a POST whose path ends in a colon and a verb: POST …/{id}:{verb} on one record, such as POST /v1/subscriptions/{subscriptionId}:settle, and POST …:{verb} on a whole collection, such as POST /v1/holders:onboard. A colon always marks a write. This page is written from the API document, as the reference is.

Business areas

Under an instrument

The resources of one instrument, under /v1/instruments/{instrumentId}:

Under a holder

The resources of one holder, under /v1/holders/{holderId}: Related: How the API works · Build a client