Cap Table, Waterfall & Fund API

The tools on this site run on a set of calculation engines: build a cap table from a list of events, run an exit waterfall against a valuation, forecast a fund's economics. Those engines are also reachable directly. You send the same inputs the tool would send and get back the same computed result, so you can run the math from a script, a spreadsheet add-on, or an AI agent instead of the browser.

Three engines are on the API, and each one is its own endpoint with its own request shape and its own access rule. This page walks them one at a time: what each computes, what you post, what comes back, and what it costs.

This is the compute API. It runs the model engines. It is not the Reporting API, which is a different surface that reads and writes your fund's data inside the Portfolio Reporting software. If you are looking to pull LP positions or post a portfolio metric, that's the one you want.

The living, machine-generated reference lives at hemrock.com/developers, with the full request schemas and status codes for every endpoint. This page is the narrative version: how to get a key, how to authenticate, and how to make a call against each engine.

Get a key

Keys are created under Settings → API keys. You'll see the raw token once, at creation, and never again. It looks like hk_live_…. Only a hash of it is stored, so if you lose it you generate a new one rather than recovering the old.

Treat the key like a password. It carries your account's access. If it leaks, revoke it from the same page and the next call it makes fails immediately.

Authenticate

Send the key as a bearer token on every request:

Authorization: Bearer hk_live_...  

There are no cookies and no session to manage. The v1 routes live outside the site's session wall, so a key is the only thing that identifies you. That's what makes them safe to call from a headless script or an agent.

One key covers all three engines, but each call runs against your account's product entitlements, and those differ by engine. The cap table and waterfall endpoints need the paid Cap Table & Exit Waterfall product. The fund endpoint is free with any valid key. Each section below says which applies.

The base URL is https://www.hemrock.com/v1 (an api.hemrock.com alias is coming, and points at the same routes).

The cap table API

POST /v1/cap-table/compute folds an ordered list of financing events into the ownership that results from them. It's the engine behind the Cap Table & Exit Waterfall tool, so a payload built here and a table built in the tool produce identical numbers.

What you send. A single events array, in chronological order. Eight event types are supported: common_issuance, option_pool, option_grant, manual_issuance, secondary_sale, convertible_round, warrant_round, and priced_round. Each carries a label and the fields that type needs, so a priced round takes a pre-money valuation, its investments, and any pool it opens.

What comes back. One snapshot per event under data.snapshots, plus data.final for the state after the last one. A snapshot holds the holdings, the fully-diluted total, the ownership rows, and any convertibles still outstanding. A priced round also stamps its pricePerShare and a roundDetail breakdown you can audit against.

Access. Requires the Cap Table & Exit Waterfall product. A valid key without it returns a 402.

Here's a cap table computed from a single founder issuance:

curl -X POST https://www.hemrock.com/v1/cap-table/compute \  
  -H "Authorization: Bearer hk_live_..." \  
  -H "Content-Type: application/json" \  
  -d '{  
    "events": [  
      { "type": "common_issuance", "label": "Founders",  
        "grants": [{ "id": "f", "name": "Founder", "shares": 8000000, "kind": "founder" }] }  
    ]  
  }'  

The exit waterfall API

POST /v1/exit-waterfall/compute takes a cap stack and an exit price and works out who gets what. Preferences pay first, each series decides whether to keep its preference or convert to common, participation and caps apply, and options and warrants come in where they're in the money.

What you send. Two fields: a model object and a numeric exitValuation. The model carries common and preferred at minimum, and optionally options, warrants, convertibles, unissuedPool, plus debt and transactionExpenses for anything paid off the top before equity sees a dollar.

What comes back. A data.result with distributable (what's left for equity after debt, expenses, and cash-out convertibles), a per-class breakdown, a per-series outcome that records the keep-versus-convert decision and how close the call was, a per-holder table, and per-share figures for classes that shared in the common pool. It also reports iterations and converged, because the keep-or-convert decision is solved by fixed-point iteration and you should be able to see when it didn't settle.

Access. Same product as the cap table, and the same 402 without it. Buying once covers both endpoints.

curl -X POST https://www.hemrock.com/v1/exit-waterfall/compute \  
  -H "Authorization: Bearer hk_live_..." \  
  -H "Content-Type: application/json" \  
  -d '{  
    "model": {  
      "common": [{ "id": "f", "name": "Founder", "shares": 8000000 }],  
      "preferred": [{ "id": "seed", "name": "Seed", "seniority": 1,  
        "holders": [{ "id": "sf", "name": "Seed Fund", "shares": 2500000, "invested": 2000000 }] }]  
    },  
    "exitValuation": 50000000  
  }'  

The venture fund API

POST /v1/fund-economics/compute forecasts a venture fund end to end: capital calls, management fees, partnership expenses, deployment across the portfolio, a power-law return profile, carry, and what the LP and GP each end up with.

This one runs the Fund Economics Tool engine, the free aggregate fund forecast. Everything resolves over fund life rather than by quarter. The full Venture Capital Model is a spreadsheet with quarterly cash flows and no API behind it, so if you need period-by-period detail, that's the workbook, not this endpoint. The Fund Economics Tool doc covers where the two part ways.

What you send. A single inputs object. Committed capital, GP commit, fee rate or a per-year fee schedule, recycling ceiling, carry, the investment and fee periods, a portfolio block describing how capital splits across new investments and follow-ons (optionally broken out into entry stages with their own check sizes and reserve ratios), and returnTiers describing the exit distribution. Inputs are validated against the engine's schema, so a malformed body comes back as a 400 naming the field rather than as an engine crash.

What comes back. A data.result carrying the whole forecast, most lines split three ways into total, LP, and GP. Capital accounting (committed, called, fees, expenses, invested, recycled), returns (gross proceeds, carry paid and earned, distributions), gross and net multiples, gross and net IRR, and the standard ratios: PIC, DPI, RVPI, TVPI. You also get the weighted hold period, total fund life, and a per-tier breakdown of where the proceeds came from.

Access. Free. Any valid key works, with no entitlement check and no 402.

curl -X POST https://www.hemrock.com/v1/fund-economics/compute \  
  -H "Authorization: Bearer hk_live_..." \  
  -H "Content-Type: application/json" \  
  -d '{ "inputs": { "committedCapital": 25000000, "carryPct": 0.2, "mgmtFeePct": 0.02 } }'  

The full input object has more fields than that, and the defaults the tool ships with are the ones in the OpenAPI example. Start from those and change what you care about.

Discovery

Two endpoints answer "what's here" without a key at all, which is what lets an agent find the API before it has credentials:

• GET /v1/catalog: the three models, their endpoints, whether each is free, and a checkout URL for the paid ones.
• GET /v1/openapi.json: the machine-readable OpenAPI spec, with every request schema field by field.

I keep the schemas there rather than copy them here so the two never drift apart. The developer reference renders the same spec for humans.

What doesn't have an API

The spreadsheet models are a different thing. The Standard Financial Model, the Venture Capital Model, and the forecasting tools are Excel and Google Sheets workbooks you download and edit directly, so there's nothing to call. If you want to move data in or out of one, that happens in the spreadsheet: link a forecast into the Forecast sheet (see building custom forecasts), or import and export cap table ownership through OCF.

Errors

Every failure comes back the same shape across all three endpoints, with a stable code you can branch on:

{  
  "error": {  
    "code": "payment_required",  
    "message": "This API needs the Cap Table & Exit Waterfall product.",  
    "retryable": false  
  }  
}  

A missing or bad key is a 401. A valid key without the required product is a 402, and its details carry the checkoutUrl, so an agent can resolve the block and retry. A malformed body is a 400 that names what was wrong. Input that parses but the engine rejects is a 422.

From an agent (MCP)

If you're driving this from Claude or another AI client, you don't have to write HTTP at all. The same three engines are exposed as MCP tools: cap_table_compute, exit_waterfall_compute, and fund_economics_compute, called natively. Add the connector at https://mcp.hemrock.com/mcp, drop your hk_live_ key into it, and it forwards that key as the bearer token on every compute call. The discovery tools (list_models, get_access) work without a key. The full guide is at hemrock.com/mcp.

Where to go next

For what the engines are actually computing, the concept guides are the place to start: equity and ownership covers how a cap table is structured, exit waterfalls walks through the allocation math, and the Fund Economics Tool explains the fund forecast the third endpoint runs. If you'd rather work in a spreadsheet than in code, the Cap Table & Exit Waterfall tool runs the same engines with every cell open.