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/docs/api, 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

Sign in to your Hemrock account and open the developer dashboard. Creating a key is free, and you do not buy anything first: every account starts with 10 lifetime free successful calculations per product. Create an API key there, or connect a compatible MCP client with OAuth. Browser calculations stay free too.

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.

A paid annual term is what you buy once the free calculations run out, not a prerequisite for a key. The Pricing page has the cost and the access terms, and Price, allowance, and limits below covers how the allowance is counted, reset, and cancelled.

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 the matching account/product allowance. Cap table and exit waterfall share one allowance; fund economics has an independent allowance. Paid terms and the calculations they include are on the Pricing page.

The primary base URL is https://api.hemrock.com/v1. The same routes are also available at https://www.hemrock.com/v1.

Price, allowance, and limits

Cost and access terms live on the Pricing page. What follows is how a given term is counted, reset, and cancelled.

• 10 lifetime free calculations per account per product. Cap table and exit waterfall share ten; fund economics has its own ten. Sign-in is required. Free credits never replenish. Active paid terms use paid credits first and do not fall back to free credits when exhausted. After expiry, genuinely unused free credits remain usable.
• $20 per product per year, billed annually. Each paid term includes 6,000 successful endpoint calculations. Buying both products costs $40/year and gives two independent allowances.
• One endpoint run is one calculation. A cap-table run followed by a waterfall run uses two calculations from their shared balance. An MCP call is charged only at the underlying API endpoint, not twice. Browser calculations, personal editing/saving, and access/usage checks do not consume this allowance.
• Account-level usage. All your keys and MCP connections share the product's balance. Additional keys do not provide additional calculations. Model validation and engine failures do not consume calculations.
• Annual reset, not a daily quota. The paid billing term determines the reset date. Unused calculations do not roll over. Daily usage history uses UTC and does not reset the annual balance.
• No automatic overages. When the allowance is exhausted, compute returns 403 quota_exceeded until the next paid term. There are no automatic top-ups or surprise usage charges.
• Manage renewal in the developer dashboard. Cancel renewal through Manage billing; an already-paid term remains available until its end. A failed renewal does not issue another allowance. Purchases of spreadsheet files do not grant perpetual hosted compute.
• Request limits: 60 compute attempts per minute per account/product, 256 KB JSON input, and 4 MB output. Cap-table requests allow up to 200 events; nested arrays up to 500 entries. Waterfalls allow up to 20 preferred series and 100 convertibles. Fund horizons are limited to 100 years. The schemas specify further field bounds.

Need more calculations? Enterprise pricing is available. Contact me to discuss your API or MCP usage.

Safe retries and usage checks

Send a unique Idempotency-Key header (1–128 printable ASCII characters) for each intended calculation. If a request times out or returns a retryable error, send the same key and identical inputs again. Completed results are replayable for 24 hours without another charge. Reusing the key with different inputs returns 409 idempotency_conflict; a still-running request returns 409 in_progress. After the replay window, use a new key only if you want a new, billable calculation. Calls without a key cannot be deduplicated.

Successful responses include meta.allowance with source, free/paid remaining, expiration, operation cost and next action, as well as meta.requestId and the remaining balance in meta.usage; replay responses have meta.replayed: true. GET /v1/access shows current product access. GET /v1/usage?from=2026-01-01&to=2026-01-31 returns daily outcomes for an inclusive UTC range of up to 366 days. Neither read consumes calculations. The dashboard shows the same account-level usage.

Request bodies are not stored in the compute ledger. Successful outputs are replayable for 24 hours, then cleared by the next successful scheduled maintenance run. Accounting records retain product, endpoint, credential identifier, source, timestamps, and outcome; daily history includes completed successful and failed attempts, not every rejected authentication or validation request.

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. Runs against the Cap Table & Exit Waterfall allowance. The ten free lifetime calculations cover it until they run out; after that it needs an active paid annual term, and a valid key without one 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 and the same allowance as the cap table, so the free calculations and any paid term both cover this endpoint. Buying once covers both.

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 same one the browser tool uses. It answers with the lifetime totals and with the fund laid out over time, by year unless you ask for quarters. The full Venture Capital Model is still a spreadsheet with no API behind it, so graduation-rate portfolio construction and the American and SPV waterfalls live in the workbook. The Fund Economics Tool doc covers where the two part ways.

What you send. An inputs object, plus three optional fields. 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.

granularity is "year" (the default), "quarter", or "none" for the totals alone. firstCloseDate (YYYY-MM-DD) dates the statements; it defaults to January 1 of the current year. features carries the optional blocks, and each applies only when it's there: waterfall (a preferred return as an IRR or a multiple, GP catch-up, tiered carry), fees (committed, NAV, AUM or step-down fee bases), followOn (follow-on timing in quarters), recycling (which quarters' proceeds are recycled, up to how much, and whether each is never distributed or distributed and recontributed), lpClasses (LP classes with their own commitments, carry, fees and first-loss treatment, each called as the fund needs cash or on a callSchedule of its own), capTable (returns derived from a cap table instead of return tiers) and mgmtCo (a management company budget against fee revenue). The OpenAPI schema has every field.

waterfall also takes the terms LPAs word differently, so the same LPA gives the same split here as in the books: preferredReturnCompounding ("annual" or simple, "none"), preferredReturnBase ("unreturned" capital or each "contributed" dollar from its date), catchupMeasure ("preferred", a share of the pref paid, or "profit", a share of all profit), and an irrThreshold on a carry tier that steps up at an LP IRR instead of a multiple. The Excel workbook carries all four as live formulas. basis: "deal-by-deal" runs American terms, where LPs get back only the capital in deals exited or written off before carry, and the clawback still settles on the whole fund. The workbook carries it too, on a Deals sheet that shows the capital in realized deals and the pref accruing on them. On fees, a schedule states the fee the way an LPA dates it: how often it's charged, and each rate and what it's charged on (commitments, invested capital or NAV) from the fund year it starts, with an optional cap on organizational expenses above which they come off the fee.

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, geometric annualized return estimates (legacy fields grossIRR and netIRR), 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.

Expenses can be itemized. operationalExpenseLines and partnershipExpenseLines each take a label and an annual amount, and a line can add quarterly, four amounts for Q1 to Q4 of each fund year, when it isn't paid evenly (an audit billed once a year, tax work in two payments). The lines are used when they add up to operationalExpensesAnnual or partnershipExpensesAnnual. Partnership expenses stop when the fund life ends. Operational expenses run on through Q1 of the following fund year, because the last year's audit, tax returns and fund admin still get billed after the final exit, so the periods can run a quarter or a few past the fund life.

Unless granularity is "none", a data.detail comes back too. periods has one entry per year or quarter for calls, fees, expenses, investments, recycling, proceeds, distributions and NAV (each split total, LP and GP), along with carried interest, DPI, RVPI, TVPI and the LP J-curve. recycledDeemed is the part of recycling booked as distributed and recontributed, which is in calls and distributions as well. Distributions run through the waterfall period by period: LPs get back what has been called so far before any carry, so a strong early exit can pay carry before the last call, and when the fund ends gpClawback returns whatever carry is above the GP's whole-fund share (send waterfall.clawback: false to switch it off), and with a waterfall block the preferred return accrues from the dates capital was called, so periods also carries preferredReturn and gpCatchup. irr holds gross and net IRRs solved from those dated cash flows, which is the number to quote as an IRR. statements has a statement of operations, a balance sheet and a cash flow statement per period (operations, balanceSheet, cashFlow), with the same lines as the Statements sheet in the Excel workbook: expenses (with operationalExpenseLines and partnershipExpenseLines when they're itemized), realized and unrealized gains, investments at cost and at fair value, partners' capital by LP and GP, operating and financing cash flows, and check lines that are zero when the balance sheet balances and the cash flow ties to it. waterfall, lpClasses and mgmtCo appear when you sent that feature. Each LP class comes back with its lifetime totals, its calls, distributions and net IRR by period (periods.netIRR, with its share of LP NAV as the value at each period's end), and a datedNetIRR solved from the dated quarterly flows, so a class called on a schedule shows what that timing does to its return.

Access. Requires an authenticated account with unused Fund Economics free credits or an active paid term. It includes 6,000 successful calculations per annual term and is independent from the cap-table and waterfall allowance.

curl -X POST https://api.hemrock.com/v1/fund-economics/compute \  
  -H "Authorization: Bearer hk_live_..." \  
  -H "Content-Type: application/json" \  
  -d '{  
    "inputs": {  
      "committedCapital": 25000000,  
      "gpCommitPct": 0.02,  
      "gpCommitCountedTowardInvested": true,  
      "organizationalExpenses": 150000,  
      "operationalExpensesAnnual": 100000,  
      "partnershipExpensesAnnual": 0,  
      "mgmtFeePct": 0.02,  
      "recycledCapitalPct": 0.10,  
      "carryPct": 0.20,  
      "newInvestmentPeriodYears": 4,  
      "mgmtFeesPeriodYears": 10,  
      "portfolio": {  
        "newPct": 1,  
        "followPct": 0,  
        "avgCheckSizeNew": 750000,  
        "avgCheckSizeFollow": 0  
      },  
      "returnTiers": [  
        { "name": "writeoff", "pctOfCapital": 0.60, "multiple": 0, "holdingPeriodYears": 2 },  
        { "name": "small", "pctOfCapital": 0.20, "multiple": 1.5, "holdingPeriodYears": 3 },  
        { "name": "medium", "pctOfCapital": 0.10, "multiple": 5, "holdingPeriodYears": 4 },  
        { "name": "large", "pctOfCapital": 0.10, "multiple": 32, "holdingPeriodYears": 6 }  
      ]  
    }  
  }'  

Start from that complete object and change what you care about. Percentages are decimals, so 0.20 means 20%. portfolio.newPct and portfolio.followPct must total 1, as must the pctOfCapital values across returnTiers. Leave out fundOperationsYears and the fund runs until its last investment, follow-ons included, has had its longest hold; pass it only to force a fixed life. Optional entry-stage, fee-schedule, and expense-breakout fields are shown in the OpenAPI example.

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/account and your client asks you to sign in to Hemrock when you add it. That sign-in is what compute runs on. The discovery tools (list_models, get_access) work without one.

The public URL, https://mcp.hemrock.com/mcp, installs the reference and discovery tools without a sign-in, and runs compute only if the connector sends Authorization: Bearer hk_live_…. If Claude tries a compute tool before you've signed in or bought access, the tool replies with what's missing and the links to fix it. If your client can't sign in to a connector or send a header, use the REST endpoint above. The full connector guide, including a header-configured example and a starter fund-model prompt, 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.

Comparisons, result retrieval and cap-table handoff

POST /v1/compute/batch accepts quote (defaults to true) and 1–5 cases, each with engine and its normal input payload. Cases must belong to one product. A quote validates inputs and returns estimated cost and current allowance without reserving credits. Show this before execution. Execute with quote: false and an Idempotency-Key header. All new cases reserve atomically; insufficient capacity executes none. Only successful cases charge. A changed comparison under the same key conflicts. Each requested exit value costs one waterfall calculation; a preceding cap-table execution is another calculation.

POST /v1/cap-table/to-waterfall maps an owned, retained cap-table requestId and explicit terms without charging. Supply preference multiple, participation/cap, seniority, invested basis by holder, zero dividends, option strikes and vested fractions, debt, transaction expenses and cancellation of unissued options. See OpenAPI for the schema. Outstanding convertibles, nonzero dividends and mixed conversion ratios or warrant strikes require a separately specified waterfall model. This avoids inventing economic rights or counting converted SAFEs twice.

GET /v1/results/{requestId} retrieves an owned successful result and CSV calculated values, without rerunning it. Add ?format=csv for a download using the same bearer authorization. Results are retained for 24 hours; this is not permanent scenario saving. The CSV contains values, not formulas. Existing browser save/share/workbook export flows remain available.

In the fund engine, result.grossIRR and result.netIRR annualize multiples over weighted holding periods; detail.irr is the IRR from dated cash flows. Management-fee revenue alone does not establish management-company profitability; send a mgmtCo block with operating costs for that.

The two focused ChatGPT plugins are in development. Plugin tools use account access without promoting subscription plans, checkout or upgrades, consistent with current platform rules. No public installation links are available yet.