Integration Overview

📘

Integrating through Apex AscendOS?

The product guidance on this page applies to you. The endpoints, fields and statuses are Monark's; use the AscendOS equivalents listed in Building on Apex AscendOS.

Monark's private markets APIs give brokerage and wealth platforms programmatic access to late-stage private companies. Your platform owns the investor experience end to end. Monark sources the shares, forms and administers the SPV that holds them, produces the offering and subscription documents, accepts subscriptions, and maintains positions, statements and tax documents for every investor.

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

Registered funds build on the same foundations. See Registered Funds.

How an Investment Flows

1. Open the account. Every transaction is placed for an investor or an account. Create the parties once, then reuse them.
2. Record accreditation. Private offerings under Regulation D are for accredited investors. Monark refuses a transaction whose accreditation is missing, expired or NOT_APPLICABLE.
3. Present the catalogue. Show live SPV offerings, upcoming prospective offerings, and the companies behind them.
4. Present the offering. Show pricing, fees, allocation, the funding deadline and the deal documents, so the investor can make an informed decision.
5. Check the cash. Before you submit, confirm the investor's cash balance and lock or debit the amount. Monark does not hold investor cash and cannot see it.
6. Create the transaction. POST /primary/v2/transaction with a dollar amount. Branch on the response.
7. Complete the required actions. Read each action Monark returns, present it, and report it complete. When the last one for a responsible party is done, the transaction moves to Processing and the subscription agreement is countersigned.
8. Track to close. Follow the transaction by webhook until it reaches Complete, at which point the investor holds a position in the SPV.

Before You Begin

Core Concepts

Conventions

Authentication. Send your API key in the Authorization header on every request. Both Authorization: <key> and Authorization: Bearer <key> are accepted. Keys expire, and an expired key fails authentication rather than degrading.

Environments. Sandbox and production are separate deployments with separate keys and separate data. An investor created in sandbox does not exist in production.

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

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

Webhooks. Status changes are delivered by webhook, so your platform does not need to poll. Events can arrive out of order, so treat each one as a signal and re-read the record with a GET before acting on it. See Webhooks.

Units. Subscriptions are denominated in dollars (amountReservedDollars, up to 2 decimal places). Share quantities, where they appear, carry up to 6 decimal places — SPV interests are fractional.

Idempotency. POST requests accept an optional IdempotencyKey header. Send one on every transaction submission so that a retry after a timeout cannot create a duplicate. Keys are cached for 24 hours.

Identifiers you supply. These are echoed back on every read and are the simplest way to reconcile Monark's records with your own:

Enumerations are case-sensitive. Send Subscription, not SUBSCRIPTION. Accreditation statuses are sent as strings exactly as written, for example NET_WORTH_GT_1M.

Only subscriptions. A Pre-IPO SPV transaction can only be a Subscription. Redemption and Transfer are supported for registered funds, not for SPVs.

Transaction Lifecycle

A subscription to an SPV reaches exactly six of the eight TransactionStatus values. Initiated and PendingCancellation are produced only for registered-fund and drawdown transactions, never for an SPV.

Note the spelling: Canceled, with one l.

Important: A Pending order reserves nothing. Allocation and seats are consumed at Processing, not at creation, so two investors can both hold pending orders that together exceed what is left. Monark re-validates the stage, the investor, the remaining allocation and the seat count at the moment the last action completes — which means a subscription that was accepted can still be refused on the way to Processing. Your UI has to handle that late failure, not just the one at create time.

Important: Branch on status, not only on the HTTP status code, and show the returned message to the user. A refused subscription returns a message naming the reason — the minimum commitment, the remaining allocation, or the seats left in the SPV — and those are all correctable by the investor.

There is no partner-callable way to settle or complete a transaction. Both are driven by Monark as the SPV closes.

Constraints Worth Knowing Before You Design

These catch integrations out late, when they are expensive to accommodate.

Data Access

A partner key sees only its own investors. Companies, investments and SPVs are visible to every partner; investors, transactions, indications of interest and questionnaire responses are scoped to the partner that created them. See Data Access Patterns.

Next Steps

• Understand the operational lifecycle and who does what: Product Flow Overview
• Handle status changes without polling: Webhooks
• Take a subscription end to end in the sandbox: Sandbox Walkthrough
• Confirm you are ready for production: Go-Live Checklist