Integration Overview

Monark's Omnibus platform enables distribution and model portfolio platforms to programatically trade evergreen funds: interval funds, tender offer funds, non-traded REITs, and non-traded BDCs. Your platform owns the investor and advisor experience, and your clients' accounts are held with their custodians. Monark supplies the fund catalogue, evaluates each fund's disclosure and suitability requirements, accepts orders, and maintains positions and distributions for every account.

These guides walk through each surface of a typical integration in the order you would build it. Every guide lists the endpoints it uses, maps API fields to UI elements, and shows a reference implementation.

What You Will Build

How an Investment Flows

1. Identify the account. Every order is placed for an accountId. Create the account and its owners once, then reuse it.
2. Present the catalogue. List the available funds, with the entry minimum of each.
3. Present the fund. Show terms, liquidity, share classes, NAV history, fees, and documents so the user can make an informed decision.
4. Evaluate requirements. Ask Monark which disclosures, signatures, and questionnaires apply to this account, advisor, fund, share class, and side.
5. Complete requirements. Collect each acknowledgement or answer in your UI and report it to Monark.
6. Submit the order. Send a Buy order in dollars, or a Sell order in shares. Inspect the status of the response.
7. Track to settlement. Follow the order until it reaches Settled, at which point it is reflected in the account's positions.

Model portfolio platforms follow the same sequence, but evaluate requirements and submit orders for many accounts at once. See Model Orders and the Rebalancing Guide.

Before You Begin

Environments & Conventions

Omnibus is a JSON REST API. Fund, order and position endpoints sit under /primary/v1/omnibus, and account, document and webhook endpoints are shared with Monark's other products.

Pagination. List endpoints accept page (default 1) and pageSize (default 25, maximum 1000), and return an items array alongside a pagination object:

{
  "items": [],
  "pagination": { "totalRecords": 65, "totalPages": 3, "currentPage": 1 }
}

Duplicate protection. Every order and model order needs a referenceId that is unique across your platform. Resubmitting a referenceId that has already been used is refused with 409 (DuplicateReferenceId), so retrying a timed-out request with the same referenceId can never create a second order. The later model order steps are just as safe to retry: a batch of lines that was already added is refused with DuplicateOrderReferenceId, and a model order that was already completed with ModelOrderNotDraft. POST requests also accept an optional IdempotencyKey header, valid for 24 hours, but it is best-effort. Rely on referenceId.

Webhooks. Order, funding and distribution events are delivered by webhook, so your platform does not need to poll for status changes. See Webhooks.

Units. Buy orders are denominated in dollars (notionalAmount, up to 2 decimal places). Sell orders are denominated in shares (quantity, up to 6 decimal places). Only USD is supported.

Enumerations. Send enum values exactly as documented: Buy and Sell, Cash and Drip, and FIFO, LIFO, HCFO, or LCFO. Responses always use these spellings.

Identifiers

Data Model

Every client account belongs to one custodian, which the API calls a Financial Institution. Orders, positions and dividends all hang off the account.

flowchart LR
    P[Partner] --> FI[Financial Institution<br/>custodian]
    FI --> A[Account]
    A --> OW[Person or Entity<br/>owners]
    A --> ORD[Order]
    MO[Model order] --> ORD
    ORD --> SC[Share class]
    F[Fund] --> SC
    F --> FEE[Fee structure]
    SC --> NAV[NAV report]
    A --> POS[Position]
    POS --> LOT[Lot]
    LOT --> DIV[Dividend]

Arrows point from parent to child. A model order's lines become individual orders, one per client account.

Order Lifecycle

Important: An HTTP 201 from an order endpoint means the request was processed, not that the order was accepted. A refused order can be returned as 201 with a status of Rejected. Always branch on status, and show the returned message to the user.

When you're ready to go live, work through the Go-Live Checklist.