Partner API

Last updated: 17 August 2026

This documentation covers the Alternatives Partner API (v3) — the customer-facing interface for programmatic access to Alternatives’ private-market data across Southeast Asia. It is a read-only REST API that returns JSON and is intended for external API subscribers. Access is subscription-gated — each endpoint is protected by entitlements that are enabled according to your subscription.

v3 replaces v2. If you are migrating from the legacy API at api.alternatives.pe/api/v2, see the Migration Guide for a full breakdown of what changed.

What the API Covers

New to the API? The Data Model page explains how Profiles relate to the underlying Legal Entity and what each UUID identifies.

Base URL

https://api.altdmp.io/v3/partners/

All endpoints are relative to this base. For example, to list capital receivers:

curl https://api.altdmp.io/v3/partners/capital-receivers/ \
  -H "Authorization: Bearer YOUR_TOKEN"

import requests

BASE = "https://api.altdmp.io/v3/partners"
headers = {"Authorization": "Bearer YOUR_TOKEN"}

resp = requests.get(f"{BASE}/capital-receivers/", headers=headers)
print(resp.json())

Request Format

Most list endpoints support two calling styles:

• GET — query-string filters (search, ordering, limit, offset)
• POST — JSON body for advanced range queries, multi-value filters, and boolean logic

On POST, the request body accepts only the filters object. Pagination and sorting (search, ordering, limit, offset) are always query parameters — sending them in the body returns 400 Bad Request.

Filtering has its own page. Filtering is the reference — every operator with its exact matching behavior, the accepted body shapes, the supported filter field list for each endpoint, and the cases where a filter is accepted but not applied.

filters goes in the body, never on the query string. The two directions are not interchangeable: search, ordering, limit, and offset are query parameters only, and filters is a body parameter only. A request that puts a value in ?filters= returns 400 Bad Request — it is not applied, and it is not ignored. A bare ?filters= with no value expresses no filter and is accepted. The sole exception is /investors/, which ignores a query-string filters and returns unfiltered results; do not rely on that.

Pagination

All list responses are paginated. Use limit and offset query parameters:

# Page 2 of results (20 per page)
curl "https://api.altdmp.io/v3/partners/capital-receivers/?limit=20&offset=20" \
  -H "Authorization: Bearer YOUR_TOKEN"

resp = requests.get(
    f"{BASE}/capital-receivers/",
    params={"limit": 20, "offset": 20},
    headers=headers,
)

Responses include count, next, and previous fields alongside results.

A few non-list responses omit the pagination keys entirely. The cap table endpoints, for example, drop count / next / previous when the company has no cap table on file. Read results rather than branching on count.

Field Types and Nulls

Three conventions run through every response and are worth setting up for once rather than discovering per endpoint.

Every numeric value is a JSON number. Amounts, percentages, multiples, and rates are returned unquoted — 925652927.23, not "925652927.23". This applies to every endpoint and every field: there is no longer any field that returns a number as a quoted string.

This changed on 2026-08-14. Amounts, percentages, and multiples were previously returned as quoted strings. If your integration parses them as strings (v.replace(...), parseFloat(v) on a value you assume is text, a schema that types them as string), it will break. See the changelog entry for the full list of affected fields.

Values carry the precision they are stored with, so the number of decimal places varies by field and sometimes between two fields with the same name — 0.1800, 40.0000, and 374.0000000000 are all valid. Read the value, not the digits. Trailing zeros are a fidelity guarantee, not a display instruction; most JSON parsers discard them anyway (JSON.parse("0.1800") gives 0.18), and nothing about how a value should be formatted can be inferred from them.

If you need exact decimal arithmetic — summing money, comparing valuations — parse into a decimal type rather than a float, the same as you would for any other JSON API. Python’s json module accepts parse_float=decimal.Decimal; in JavaScript, parse with a big-decimal library rather than the native number.

The field name tells you the scale of a percentage. For any value expressing a proportion, you never have to guess whether 0.1875 means 18.75% or 0.1875%:

Where both forms exist they are siblings covering the same figure: irr_pct is always exactly irr × 100. Filters and ordering keys use the scale of the field they name — irr_min=0.15 means 15%.

The rule covers proportions only. Two other kinds of value have rate-like or ratio-like names and are neither a fraction nor a percentage, so neither has a _pct sibling:

• Multiples — dpi, rvpi, net_multiple. A dpi of 1.80 means 1.8×, not 180%.
• Conversion factors — an exchange rate of 1.3450 is a multiplier between two currencies. There is no percentage reading of it.

null means unknown, not zero or false. Nullable booleans (is_raising_now, is_open_to_co_investment, the fund classification flags) return null when nothing has been declared — distinct from false. Nullable amounts return null both when the value is unknown and when it is known to net to zero; they are never 0.00. A null never satisfies a numeric comparison, so rows with a null value are excluded from range filters on that field and sort to the end of an ordering on it, in both directions.

Keys and Display Values

Many concepts are returned twice: once as a stable key and once as a human-readable label. Always join, look up, filter, group, and store on the key. Treat the label as presentation only.

Keys are contractual: "capital_allocator" stays "capital_allocator". Labels are not — their exact spelling can change while the thing they describe stays the same. A relabelling would silently re-partition anything keyed on the display string, with no error and no version signal to tell you it happened.

A few fields are the key half of a pair that has no separate _key suffix, because the field itself already holds the key: investor_type ("legal_entity", "person", …), iso_alpha3, iso_code, code on industries and SIC codes, and date_founded_precision. Join on those directly.

type_key is scoped to the object it appears on — there is no single global vocabulary. On a buyer, seller, shareholder, or LP it names a kind of entity ("capital_allocator", "person", …). On legal_entity.alternate_names[] it names a kind of name ("alt_name_legal_name", "alt_name_fka"). The two never mix, but do not build one shared lookup table across both — read type_key in the context of the object holding it.

type and profile_type will change what they display. Today they present values like "CapitalAllocatorProfile" and "capitalallocatorprofile" — the same concept, spelled two different ways, and neither reads as a label. A future release will replace both with proper labels such as "Capital Allocator".

Neither field is going away, and nor is the display half of any other pair — only the presented string changes. type_key and profile_type_key are unaffected. If you join on the keys, this change is invisible to you. If you join on type or profile_type, it will break you.

Cap Table Types

Every capital receiver has a captable_source.type field that tells you how its shareholding data was collected. Always check this field before interpreting cap table results — the response shape and available data differ between the two types.

Use the captable_is_managed filter on /capital-receivers/ to segment your queries:

# Companies with full transaction-level cap table data
curl -X POST https://api.altdmp.io/v3/partners/capital-receivers/ \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"filters": {"all": [{"op": "eq", "field": "captable_is_managed", "value": true}]}}'

The same captable_source.type field and response structure applies to /capital-allocators/{uuid}/captable/.

Common Use Cases

Data Model

Last updated: 19 August 2026

Before working with any endpoint, it helps to understand two concepts that run through the entire API: the Legal Entity and the Profile. Most of the UUIDs you encounter are one or the other, and knowing which is which tells you what a given ID identifies and which endpoint it drives.

Legal Entity vs. Profile

A Legal Entity is the underlying registered organization — a company as it exists in a corporate registry, identified by its registration number (e.g. a Singapore UEN). It holds the identity and registration facts: legal name, domicile, headquarters, trading status, year founded, and registration numbers.

A Profile is a role-specific view onto an entity. The API exposes several profile types, each with its own endpoint and its own fields:

The key relationship: a single Legal Entity can back more than one profile. The same registered company may appear as a Capital Receiver (it raised money) and as a Capital Allocator (it also invests) — two distinct profiles, two distinct profile UUIDs, one shared underlying Legal Entity. This is why registration and identity data lives on the nested legal_entity object rather than being duplicated on each profile.

Not every profile is backed by a Legal Entity. A Capital Allocator can instead be backed by a Person (an angel investor, for example). Profiles carry a profile_type field of "legalentity" or "person" to indicate which. Fields that resolve through the legal entity — geography, cap table, financials — return null for person-backed profiles. See Capital Allocators.

How Many Profiles Per Root Record

A profile always hangs off a root record — a Legal Entity, or for capital allocators a Person. The root record is the identity; the profile is a role layered on top of it.

The relationship runs in two directions, and only one of them is one-to-one:

So a single company can be a Capital Receiver, a Fund, a Service Provider, and several Capital Allocators simultaneously. Each of those profiles has its own UUID, and none of them is the company’s identity — the root UUID is.

Do not assume one capital allocator profile per firm. A firm that allocates both equity and debt has a separate allocator profile, with a separate UUID, for each. Any figure you total per firm — capital deployed, number of investments, dry powder — must be collapsed on the root UUID first, or a multi-strategy firm is counted once per profile. The same applies to service providers, where there is no limit at all.

The Nested Legal Entity Object

Profile detail responses embed the shared identity data under a legal_entity object:

{
  "uuid": "c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67",
  "legal_entity": {
    "uuid": "fee788ac-cffe-46f0-9bb5-fedb62992bd8",
    "display_name": "Company Name",
    "domicile_country": {"iso_alpha3": "SGP", "name": "Singapore"},
    "trading_status": {"key": "operating", "name": "Operating"},
    "year_founded": 2020,
    "registration_numbers": [
      {
        "reg_number": "202012345A",
        "authority_type": "UEN",
        "authority_name": "Accounting and Corporate Regulatory Authority"
      }
    ]
  }
}

Here the top-level uuid is the profile UUID (a capital receiver, in this case) and legal_entity.uuid is the Legal Entity UUID. They are different IDs pointing at different things: the first drives the profile’s own endpoints, the second identifies the registered company shared across any other profiles built on it.

Understanding the UUIDs

The same underlying entity surfaces different UUIDs depending on where you are in the API. This table maps each one to what it identifies and how to use it:

Telling Which Namespace a UUID Belongs To

Rows that reference some entity without knowing in advance what kind — a deal’s buyer and seller, a cap-table shareholder, a role’s organization, an LP buyer on a commitment — carry a type_key (or profile_type_key) alongside the uuid. That key names the namespace the uuid lives in, and so which endpoint to call:

The uuid is the most specific record available, not always the legal entity. The same firm appears as capital_allocator where it has an allocator profile and as legal_entity where it doesn’t. Branch on the key before joining; a join that assumes one namespace silently drops every row in the others.

Each of these fields is paired with a display-only twin (type, profile_type) whose presented string is not stable. Join on the key. See Keys and Display Values.

Which UUID do I pass to an endpoint? Always the profile UUID. Endpoints like /capital-receivers/{uuid}/, /capital-allocators/{uuid}/, and /funds/{uuid}/ expect the profile UUID for their type — for example capital_receiver_uuid, not legal_entity_uuid. The legal_entity_uuid is a correlation key: use it to recognize when two rows or two profiles refer to the same registered company. There is no /legal-entities/{uuid}/ endpoint.

Counterparty UUIDs Are Not Stable Identifiers

The uuid on a buyer, seller, shareholder, organization, or investor row is resolved per row, at the time you fetch it, to the most specific profile that entity currently has. It is a handle for fetching detail, not an identity. Two behaviors follow from that, and either one will fork an entity-resolution table keyed on it.

The same company resolves differently depending on the role it plays in the row. Where a company is the outside investor, it resolves to its capital allocator profile. Where the same company is the one being invested in, it resolves to its capital receiver profile. One company, two rows, two different UUIDs and two different type_key values — with nothing tying them together in the response.

The UUID changes when a profile is added later. A company with no allocator profile is reported as {"uuid": "<legal entity uuid>", "type_key": "legal_entity"}. Once an allocator profile exists for that company, the same historical transaction starts returning the allocator profile’s UUID with type_key: "capital_allocator". Nothing about the transaction changed, the record was not corrected, and no field in the response indicates the identifier moved.

So do not use these UUIDs as an entity-resolution key. Key your own company or party table on the root UUID — legal_entity.uuid for an organization, the person UUID for an individual — and treat the counterparty uuid as a per-row pointer you re-read on every sync.

Where To Get A Root UUID

For that last row, resolve the root by fetching the profile’s own detail response and reading legal_entity.uuid. That is one request per profile: legal_entity_uuid is a filter field on /service-providers/ alone, so a set of capital receiver, allocator, or fund UUIDs cannot be crosswalked to their root records in bulk. Plan the resolution step into your ingestion rather than assuming a batch lookup exists.

Some rows have no root record at all. Pooled and unnamed holders — an ESOP pool, an “Other Shareholders” aggregate, a shareholder_group — are not backed by a legal entity or a person, so there is no root UUID to resolve. type_key is other, alt, shareholder_group, or null on these; treat them as unresolvable rather than minting a company for them.

Why Two IDs on the Same Row

Investment rows — the /investments/ sub-resource on capital allocators, funds, and people — carry both capital_receiver_uuid and legal_entity_uuid:

{
  "capital_receiver_uuid": "c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67",
  "legal_entity_uuid": "fee788ac-cffe-46f0-9bb5-fedb62992bd8",
  "capital_receiver_name": "Shopback"
}

Use capital_receiver_uuid to navigate to the company’s profile. Use legal_entity_uuid to group or reconcile rows at the registered-company level — for example, to see that two holdings belong to the same legal entity even when they surfaced through different profiles.

This pairing is specific to investment rows. Cap-table rows carry neither: a managed or snapshot cap-table row identifies its holder through the nested shareholder object and nothing else. See Counterparty UUIDs Are Not Stable Identifiers.

Authentication

Last updated: 17 August 2026

Every request to the Partner API must include a Bearer token in the Authorization header.

Obtaining a Token

Exchange your API key for a short-lived access token:

curl -X POST https://api.altdmp.io/v3/token/issue/ \
  -H "Content-Type: application/json" \
  -d '{"api_key": "YOUR_API_KEY"}'

import requests

resp = requests.post(
    "https://api.altdmp.io/v3/token/issue/",
    json={"api_key": "YOUR_API_KEY"},
)
token = resp.json()["access_token"]

Response:

{
  "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ij...",
  "token_duration": 1440,
  "expires_at": "2024-11-21T06:29:30.396717Z"
}

The token is valid for 24 hours (token_duration is in minutes).

Contact support@alternatives.pe to obtain your API key.

Using the Token

Include the token in the Authorization header on every request:

curl https://api.altdmp.io/v3/partners/capital-receivers/ \
  -H "Authorization: Bearer YOUR_TOKEN"

headers = {"Authorization": f"Bearer {token}"}
resp = requests.get(
    "https://api.altdmp.io/v3/partners/capital-receivers/",
    headers=headers,
)

Subscription and Access Control

Authentication alone is not sufficient. Each endpoint is also protected by entitlements that are enabled according to your subscription. Your organisation must hold the appropriate entitlements for the resources you need to access.

Entitlements are provisioned automatically when your subscription is activated. Different subscription tiers unlock access to different endpoints and data types. See Plans & Access for the full per-endpoint breakdown by plan. Contact support@alternatives.pe to review or upgrade your subscription.

A 403 Forbidden response means your organisation’s subscription does not include access to that endpoint. Contact support to adjust your subscription.

Rate Limits

The Partner API is rate limited to protect service quality for all clients. Requests are limited to 320 requests per rolling 1-minute window. The window is rolling rather than fixed: at any moment, the count is the number of requests made in the preceding 60 seconds, so capacity frees up continuously rather than resetting on a clock boundary.

When you exceed the limit, the API responds with 429 Too Many Requests and a Retry-After header indicating how many seconds to wait before retrying. The response body is a structured JSON error describing the limit that was hit.

To stay within the limit:

• Honor Retry-After. When you receive a 429, wait the number of seconds it specifies before sending the next request, then retry. Do not retry immediately.
• Back off on repeated 429s. If retries keep failing, increase the delay between attempts (exponential backoff) rather than retrying at a fixed interval.
• Spread out bulk work. Page through large result sets steadily and avoid issuing requests in tight, unthrottled bursts.

Error Responses

Errors are always JSON. Most carry two keys: status_code, repeating the HTTP status of the response, and detail, a human-readable message.

{
  "status_code": 404,
  "detail": "The requested resource was not found."
}

Every endpoint can return 401, 403, and 500; endpoints that take a UUID in the path can also return 404; endpoints that accept a body or filter parameters can also return 400. These are declared per operation in the OpenAPI schema and the Postman collection.

400 response bodies

Validation errors raised by the API put the message in a list:

{
  "status_code": 400,
  "detail": [
    "Invalid ordering field 'founded'. Valid ordering fields are: created_at, display_name, term_years, updated_at, vintage_year."
  ]
}

A few endpoint-specific checks return the message as a plain string, without status_code:

{
  "detail": "Investor summary is only available for capital receivers with a managed cap table. Use /partners/capital-receivers/{uuid}/captable/ for snapshot-based cap tables."
}

One check keys the message by the parameter at fault instead of using detail — passing filters on the query string rather than in the request body:

{
  "filters": "`filters` must be sent in the JSON request body on this endpoint, not as a query-string parameter.",
  "status_code": 400
}

When handling errors, take the status from the HTTP response rather than from the body — status_code is present on most error bodies but not all of them. Read detail and accept either a string or a list of strings, and treat its absence as a valid body: a 400 may instead carry the message under the name of the offending parameter.

Very long URLs return a non-JSON 400

The request line — the method, the full path, and the entire query string — is limited to 8190 bytes. A request over that is rejected before the API runs, so it returns 400 Bad Request as HTML, with no detail and no status_code. If you parse every error body as JSON, guard for this.

Long ?search= values and long comma-separated country or UUID lists are what push a URL over the limit. Move bulk conditions into a POST filters body, or split them across pages.

Plans and Access

Last updated: 15 July 2026

Which Partner API endpoints you can call depends on your subscription plan. This page lists every endpoint and shows whether it is included with Atlas or Allocate.

Custom plans are not covered here. The tables below describe our two standard plans. If your organisation is on a plan we’ve tailored to your requirements, your endpoint access is defined by your agreement and may differ from what’s shown here. Contact support@alternatives.pe if you’re unsure which endpoints your subscription includes.

How Access Works

Two things must be true for a request to succeed:

1. Partners API access. Programmatic access is a separate add-on to your subscription. When it’s enabled, your organisation can authenticate and call the API.
2. Endpoint entitlement. Each endpoint is individually gated by your plan. If your plan doesn’t include an endpoint, calling it returns 403 Forbidden even with a valid token — see Authentication → Subscription and Access Control.

What Differs Between Atlas and Allocate

Most endpoints are available on both plans. The differences are:

On Atlas, you can retrieve a capital receiver directly by UUID (and all of its sub-resources), but you cannot list or search the capital-receivers collection. On Allocate, the entire Funds resource and the capital-allocator LP commitments endpoint are not included.

Full Endpoint Matrix

✓ = included  ·  ✗ = not included (returns 403 Forbidden)

Capital Receivers

Capital Allocators

Funds

Investors

People

Service Providers

Reference Data

Handling 403 Forbidden

A 403 on an endpoint listed above as ✗ for your plan is expected — it means your subscription doesn’t include that endpoint. To add access, contact support@alternatives.pe to upgrade your plan or arrange a custom plan.

Migrating from v2 to v3

Last updated: 20 August 2026

The v3 Partner API is a complete redesign of the legacy VentureCap v2 API. It is not a wire-compatible upgrade — it is a new contract. This guide covers everything you need to update your integration.

What Changed at a Glance

Breaking Semantic Changes

These are not syntactic renames — they change meaning and require deliberate handling:

• Investors split by allocation type. An investor with both equity and debt allocations now appears as two separate records in API responses — one per allocation type.
• Sectors deprecated. v3.industries is a different classification system, not a rename of v2.sectors. Do not treat industry codes as mapped equivalents of sector IDs.
• Theme taxonomy reworked. v3.themes are not 1:1 with v2.themes. Treat the five-dimension classification as a new framework to adopt explicitly.
• date_incorporated maps to date_founded. The nested legal_entity exposes date_founded (full ISO date) with a date_founded_precision flag ("year" / "month" / "day"), plus a year-only year_founded for convenience.
• name is nested. v2.name maps to v3.legal_entity.display_name, not a top-level field.
• headquaters spelling fixed. v2 had a typo; v3 uses headquarters.

Authentication

v2

curl -X POST https://api.alternatives.pe/api/v2/oauth/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "client_id=YOUR_ID&client_secret=YOUR_SECRET"

Returns {"token": "..."}. Use as a Bearer token.

v3

v3 credentials are issued through PropelAuth. Contact support@alternatives.pe to provision an API key, then exchange it for a short-lived bearer token:

curl -X POST https://api.altdmp.io/v3/token/issue/ \
  -H "Content-Type: application/json" \
  -d '{"api_key": "YOUR_API_KEY"}'

import requests

token = requests.post(
    "https://api.altdmp.io/v3/token/issue/",
    json={"api_key": "YOUR_API_KEY"},
).json()["access_token"]

headers = {"Authorization": f"Bearer {token}"}

The token is valid for 24 hours. Request new credentials before starting your migration.

Identifiers

v2 used integer IDs throughout. v3 uses UUIDs everywhere — no internal integer IDs are exposed.

# v2
GET /api/v2/companies/4821/

# v3
GET /v3/partners/capital-receivers/c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67/

# v3 — store uuid from list results for later detail calls
results = requests.get(f"{BASE}/capital-receivers/?search=shopback", headers=headers).json()
uuid = results["results"][0]["uuid"]
detail = requests.get(f"{BASE}/capital-receivers/{uuid}/", headers=headers).json()

There is no mapping endpoint between v2 integer IDs and v3 UUIDs. Re-query by name or registration number to find the corresponding v3 UUID.

Pagination

v2 used a custom doubly-nested envelope:

{
  "data": {
    "total_records": 1000,
    "no_of_pages": 10,
    "limit": 100,
    "offset": 0,
    "data": [{ "id": 1234, "name": "Example Co" }]
  }
}

v3 uses a standard limit/offset envelope:

{
  "count": 1000,
  "next": "https://api.altdmp.io/v3/partners/capital-receivers/?limit=100&offset=100",
  "previous": null,
  "results": [
    {
      "uuid": "a1b2c3d4-0000-0000-0000-000000000001",
      "legal_entity": {"uuid": "b2c3d4e5-0000-0000-0000-000000000002", "display_name": "Example Co"}
    }
  ]
}

# v2
GET /api/v2/companies/?page=2&page_size=20

# v3
GET /v3/partners/capital-receivers/?limit=20&offset=20

Ordering

# v2
GET /api/v2/companies/?order_by=name&order_direction=desc

# v3 (prefix field with - for descending)
GET /v3/partners/capital-receivers/?ordering=display_name
GET /v3/partners/capital-receivers/?ordering=-last_updated_at

Each endpoint accepts a fixed set of sortable fields. An unsupported ordering value now returns 400 Bad Request with the list of valid fields, rather than being silently ignored.

Filtering Changes

v2 supported query-string filters only. v3 adds a JSON body filter via POST for complex conditions. Simple filters (search, ordering, registration_number) are still supported as query parameters.

The POST body accepts only the filters object. search, ordering, limit, and offset are always query parameters — sending them in the body returns 400 Bad Request.

There is no ?filters= query parameter. Coming from v2 it is a natural guess, and it returns 400 Bad Request. The advanced filter tree is a body parameter only. This is also the practical reason to move bulk conditions into the body: a long filter tree in the query string can push the URL past the 8190-byte request-line limit, which fails before the API runs and returns HTML rather than JSON.

# v2
GET /api/v2/companies?countries=SGP,THA&sectors=22,44&themes=35

# v3 — advanced filter via POST body (pagination and sorting go on the query string)
curl -X POST "https://api.altdmp.io/v3/partners/capital-receivers/?search=platform&ordering=-latest_valuation_usd&limit=100" \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "all": [
        {"op": "eq",  "field": "headquarters_country_iso_alpha3", "value": "SGP"},
        {"op": "in",  "field": "themes_keys", "value": ["themes_payments", "themes_climate_green_clean"]},
        {"op": "gte", "field": "latest_valuation_usd", "value": 10000000}
      ]
    }
  }'

Keys vs. display values

v2 mostly returned a single string per concept. v3 returns two: a stable key and a human-readable label. Build every join, lookup, filter, and grouping on the key — type_key, profile_type_key, allocation_type_key, allocation_deal_type_key, investor_type, and the key inside any {key, name} object. The label half (type, profile_type, *_name) is presentation only, and its spelling can change without the underlying thing changing. See Keys and Display Values.

If you are porting v2 code that keyed off display strings such as sector or theme names, this is the change to make while you are in there.

Filter Operators

range takes a list of exactly two values, low then high — {"op": "range", "field": "date_founded", "value": ["2015-01-01", "2020-12-31"]}. Any other number of values returns 400 Bad Request.

filters must be a JSON object. A list or a scalar — {"filters": ["any"]} — returns 400 Bad Request rather than applying no filter. Omitting filters, or sending null or {}, is the way to ask for an unfiltered list.

Every filter body must start with a logical operator. filters takes all, any, or not at its top level — a bare condition such as {"filters": {"op": "eq", "field": "…", "value": …}} returns 400 Bad Request. Wrap even a single condition:

{"filters": {"all": [{"op": "eq", "field": "headquarters_country_iso_alpha3", "value": "SGP"}]}}

all and any take an array of conditions. not takes a single condition object:

{"filters": {"not": {"op": "eq", "field": "headquarters_country_iso_alpha3", "value": "SGP"}}}

An array under not is also accepted and is negated as a whole — equivalent to wrapping it in all and negating that.

not needs something to negate. An empty negation — {"not": []}, {"not": {}}, or {"not": {"all": []}} — returns 400 Bad Request. There is no useful reading of “exclude nothing in particular”, and the alternative is a body that asks to exclude rows and returns every one of them. An empty all or any is different: it means you supplied no conditions, so it stays a permissive no-op and returns the unfiltered list.

Conditions nest — an entry inside all or any may itself be another all / any / not block.

A malformed condition anywhere in the body returns 400 Bad Request with a message describing the problem — a non-object where a condition was expected, or a range without exactly two values. This holds in both the nested form ({"all": ["oops"]}) and the flat, field-keyed form ({"name": {"all": ["oops"]}}).

Derived filter fields on capital receivers

POST /v3/partners/capital-receivers/ filters on the fields returned in the response and also on a set of derived ones: financials_latest_financial_year_end, latest_investment_stage_name, latest_investment_stage_key, latest_operating_revenue_usd, operating_revenue_growth_yoy_pct, latest_valuation_usd, and total_funding_usd. Each is computed only when it appears in the filter body or in ordering, so plain list and search requests are unaffected. Filter, ordering, and response all use the same field names.

Geography filters on capital allocators and funds

POST /v3/partners/capital-allocators/ and POST /v3/partners/funds/ both support geography filters via domicile_country_name, domicile_country_iso_alpha3, headquarters_country_name, and headquarters_country_iso_alpha3. For capital allocators, geography comes from the linked legal entity — allocators backed by a Person rather than a legal entity return null and are excluded when a country filter is applied.

Filter migration — capital receivers

Classification Framework

v3 replaces v2’s sector/theme model with a five-dimension classification. Do not treat any v2 dimension as a direct equivalent:

v2:

{ "sectors": [{"id": 22, "name": "Financial Services"}] }

v3:

{
  "industries": [{"code": "10", "description": "Financial and Insurance Activities"}],
  "themes":     [{"key": "themes_digital_neo_banking", "name": "Digital / Neo Banking"}],
  "techs":      [{"key": "techs_fintech", "name": "FinTech"}]
}

USD Normalization

v3 normalizes all monetary fields to USD using a deterministic FX policy. Fields are suffixed _usd (e.g., total_funding_usd, latest_valuation_usd, committed_capital_usd). Stop applying FX rates client-side once you migrate.

Response Structure: Nested Legal Entity

v3 wraps registration and identity data under a legal_entity object:

{
  "uuid": "...",
  "legal_entity": {
    "uuid": "...",
    "display_name": "Company Name",
    "domicile_country": {"iso_alpha3": "SGP", "name": "Singapore"},
    "headquarters": {
      "country_name": "Singapore",
      "country_iso_alpha3": "SGP",
      "state_name": "Central Singapore",
      "city_name": "Singapore"
    },
    "trading_status": {"key": "operating", "name": "Operating"},
    "year_founded": 2020,
    "registration_numbers": [
      {
        "reg_number": "202012345A",
        "authority_type": "UEN",
        "authority_name": "Accounting and Corporate Regulatory Authority"
      }
    ]
  },
  "themes": [{"key": "themes_payments", "name": "Payments"}],
  "industries": [{"code": "10", "description": "Financial and Insurance Activities"}]
}

v2 flat fields mapped to v3 nested equivalents:

# v2 flat field
"uen": "201411189G"

# v3 nested
"legal_entity": {
  "registration_numbers": [
    {
      "reg_number": "201411189G",
      "authority_name": "Accounting and Corporate Regulatory Authority",
      "authority_type": "UEN"
    }
  ]
}

Endpoint Mapping

Companies → Capital Receivers

Company Financials

The v2 monolithic /companies/{id}/financials splits across multiple v3 endpoints:

Capital Providers → Capital Allocators

Funds

People

v2 had separate /directors/ and /founders/ endpoints. v3 unifies them under /people/ with a role_type_key filter:

Auditors → Service Providers

New in v3 (No v2 Equivalent)

Key Field Mappings

Companies → Capital Receivers

Capital Providers → Capital Allocators

Fund Performance

Commitment Deals

Method Matrix

Complete endpoint reference for the v3 Partner API surface.

Capital Receivers

Capital Allocators

Funds

People

Investors

Service Providers

Reference Data

Coverage Gap Summary

v2 fields, filters, and endpoints that have no direct v3 equivalent.

Fields Not in v3

Filters Not in v3

v2 Endpoints Fully Deprecated

Worked Examples

Authenticate and list capital receivers

# 1. Exchange API key for access token
curl -sS https://api.altdmp.io/v3/token/issue/ \
  -H 'Content-Type: application/json' \
  -d '{"api_key": "YOUR_API_KEY"}' \
  | jq -r .access_token > /tmp/token.txt

# 2. List capital receivers
curl -sS "https://api.altdmp.io/v3/partners/capital-receivers/?search=Bunker&limit=20" \
  -H "Authorization: Bearer $(cat /tmp/token.txt)" | jq .

Filter capital receivers (POST body)

curl -sS "https://api.altdmp.io/v3/partners/capital-receivers/?search=platform&ordering=-latest_valuation_usd&limit=100" \
  -H "Authorization: Bearer $(cat /tmp/token.txt)" \
  -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "all": [
        {"op": "eq",  "field": "headquarters_country_iso_alpha3", "value": "SGP"},
        {"op": "gte", "field": "year_founded",                     "value": 2018},
        {"op": "in",  "field": "themes_keys",                      "value": ["themes_payments", "themes_climate_green_clean"]}
      ]
    }
  }' | jq .

Discover an investor and pull their portfolio

TOKEN=$(cat /tmp/token.txt)

# 1. Discover the investor — returns investor_type to determine which profile to call
INV=$(curl -sS "https://api.altdmp.io/v3/partners/investors/?investor_type=legal_entity&search=Temasek" \
  -H "Authorization: Bearer $TOKEN" | jq -r '.results[0]')
UUID=$(echo "$INV" | jq -r '.uuid')
TYPE=$(echo "$INV" | jq -r '.investor_type')

# 2. Fetch the portfolio using the appropriate profile endpoint
# investor_type=legal_entity may be a capital allocator or capital receiver — try allocator first
if [ "$TYPE" = "capital_allocator" ]; then
  URL="https://api.altdmp.io/v3/partners/capital-allocators/$UUID/investments/"
elif [ "$TYPE" = "fund" ]; then
  URL="https://api.altdmp.io/v3/partners/funds/$UUID/investments/"
elif [ "$TYPE" = "person" ]; then
  URL="https://api.altdmp.io/v3/partners/people/$UUID/investments/"
else
  # For legal_entity, try capital-allocators first
  URL="https://api.altdmp.io/v3/partners/capital-allocators/$UUID/investments/"
fi
curl -sS "$URL" -H "Authorization: Bearer $TOKEN" | jq .

Walk fund performance and AUM

FUND_UUID="your-fund-uuid-here"

curl -sS "https://api.altdmp.io/v3/partners/funds/$FUND_UUID/performance/?ordering=-date" \
  -H "Authorization: Bearer $TOKEN" | jq .

curl -sS "https://api.altdmp.io/v3/partners/funds/$FUND_UUID/aum/?ordering=-date" \
  -H "Authorization: Bearer $TOKEN" | jq .

Bootstrap reference data

# Cache enums and countries on app start
curl -sS "https://api.altdmp.io/v3/partners/reference-data/?type=enums,countries" \
  -H "Authorization: Bearer $TOKEN" \
  > reference_cache.json

# Use to populate filter dropdowns
jq '.enums.themes[] | "\(.key)\t\(.name)"' reference_cache.json

URL Cheat Sheet

Migration Checklist

• Update base URL from https://api.alternatives.pe/api/v2/ to https://api.altdmp.io/v3/partners/
• Replace client_id/client_secret auth with the API-key flow on POST /v3/token/issue/
• Confirm your subscription gives you access to the v3 endpoints you need (403 = contact support)
• Replace integer IDs with UUIDs in all API calls and persisted references
• Update pagination: parse count, next, previous, results instead of the v2 data.data[] envelope
• Convert order_by/order_direction to single ordering parameter (- prefix for descending)
• Move advanced filters from query parameters to POST filters JSON bodies — a filters query parameter returns 400
• Remove sectors usage and remap onto the v3 classification framework (themes, techs, business_models, industries, horizontals)
• Update company lookups to /capital-receivers/; look up by UEN via ?registration_number=
• Update capital-provider lookups to /capital-allocators/; read profile_type from the response
• Replace auditor lookups with /service-providers/?service_type=service_provider_type_audit
• Consolidate director/founder calls to /people/?role_type_key=person_association_director|founder
• Move person job_titles reads to /people/{uuid}/roles/
• Handle the nested legal_entity object in profile responses
• Update field names per the mapping tables (first_name → given_name, last_name → family_name, etc.)
• Update fund consumers: fetch performance via /funds/{uuid}/performance/ and AUM via /funds/{uuid}/aum/
• Migrate commitment-deal logic to the two nested commitments endpoints (per fund vs. per allocator)
• Adopt /v3/partners/investors/ and per-profile /investments/ endpoints; expect investor records to split by allocation type
• Integrate GET /v3/partners/reference-data/ to bootstrap filter dropdowns
• Stop applying client-side FX — money fields are USD-normalized with _usd suffix
• Smoke-test all endpoints in a non-prod environment before switching production traffic

Frequently Asked Questions

How long will v2 keep running?

v2 will be supported through a managed migration window communicated to each customer individually. Confirm your timeline with your customer support representative.

Do I need new credentials?

Yes. v3 issues API keys via PropelAuth, which are exchanged for short-lived bearer tokens via POST /v3/token/issue/. Request new credentials before starting your migration.

Will v3 expose everything v2 did?

Most v2 capability is preserved — either as a direct mapping or via a different shape. A small number of v2 fields are intentionally not surfaced (raw share-class IDs, news-sourced funding rounds, pre-money valuation). See the Coverage Gap Summary for the full list with workarounds.

What if my integration depends on a deprecated v2 field?

Email support@alternatives.pe with the specific field and use case. Many gaps have nearby v3 equivalents that can be adopted without losing functionality.

Filtering

Last updated: 19 August 2026

Every list endpoint in the Partner API accepts the same filter grammar: a filters object in a POST body, built from a fixed set of operators over a documented set of field names per endpoint. This page is the reference for that grammar — the operators, their exact matching behavior, the body shapes that are accepted, the supported filter fields for each endpoint, and the cases where a filter is accepted but not applied.

The endpoint pages repeat the fields most callers reach for first. This page is the authoritative list.

Where Filters Go

filters is a request-body parameter and is accepted only on POST. search, ordering, limit, and offset are query parameters and are accepted only on the query string. The two directions are not interchangeable, and swapping them never works:

A POST request goes to the same path as the GET list — there is no /filter/ suffix:

curl -X POST https://api.altdmp.io/v3/partners/capital-receivers/?limit=50 \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "all": [
        {"op": "eq",  "field": "domicile_country_iso_alpha3", "value": "SGP"},
        {"op": "gte", "field": "latest_valuation_usd",        "value": 50000000}
      ]
    }
  }'

resp = requests.post(
    f"{BASE}/capital-receivers/",
    headers=headers,
    params={"limit": 50},
    json={
        "filters": {
            "all": [
                {"op": "eq",  "field": "domicile_country_iso_alpha3", "value": "SGP"},
                {"op": "gte", "field": "latest_valuation_usd",        "value": 50000000},
            ]
        },
    },
)

/v3/partners/investors/ is the one endpoint that ignores a query-string filters instead of rejecting it, and it accepts a narrower filter grammar than the one on this page. See Investors → Advanced Filter (POST). Do not rely on the difference.

Filter Body Structure

filters must be a JSON object. A list or a scalar — {"filters": ["any"]} — returns 400 Bad Request. To ask for an unfiltered list, omit filters or send null or {}.

Two shapes are accepted at the root, and they can be combined in one body.

Logical form

The root holds all, any, or not, and each leaf condition names its own field:

{"filters": {"all": [{"op": "eq", "field": "domicile_country_iso_alpha3", "value": "SGP"}]}}

• all — AND. Takes an array.
• any — OR. Takes an array.
• not — NOT. Takes a single condition object, or an array, which is negated as a whole (the same as wrapping it in all first).

A leaf condition is {"op": …, "field": …, "value": …}. A bare leaf at the root is rejected — {"filters": {"op": "eq", "field": "…", "value": …}} returns 400 Bad Request, so wrap even a single condition in all.

Blocks nest to any depth. An entry inside all or any may itself be another all / any / not:

{
  "filters": {
    "all": [
      {"op": "eq", "field": "domicile_country_iso_alpha3", "value": "SGP"},
      {"any": [
        {"op": "gte", "field": "total_funding_usd", "value": 100000000},
        {"op": "eq",  "field": "is_raising_now",    "value": true}
      ]},
      {"not": {"op": "eq", "field": "trading_status_key", "value": "trading_status_ceased"}}
    ]
  }
}

Field-keyed form

The root can instead key on the field name, with the condition as its value and no field inside it:

{"filters": {"year_founded": {"op": "gte", "value": 2015}}}

Multiple field keys at the root are ANDed together. Within one field key you may nest all / any / not and omit field from every leaf — the field name is taken from the key:

{
  "filters": {
    "domicile_country_iso_alpha3": {"op": "eq", "value": "SGP"},
    "year_founded": {"all": [
      {"op": "gte", "value": 2015},
      {"op": "lte", "value": 2020}
    ]}
  }
}

The field-keyed form does not work on the computed capital-receiver fields. total_funding_usd, latest_valuation_usd, latest_operating_revenue_usd, operating_revenue_growth_yoy_pct, latest_investment_date, latest_investment_stage_name, latest_investment_stage_key, and captable_is_managed are backed by subqueries that are only attached when the endpoint sees the field inside a field key — which the field-keyed form does not produce. {"filters": {"latest_valuation_usd": {"op": "gte", "value": 50000000}}} returns 400 Bad Request naming an internal column (filter_latest_valuation_usd). Use the logical form for these fields:

{"filters": {"all": [{"op": "gte", "field": "latest_valuation_usd", "value": 50000000}]}}

financials_latest_financial_year_end has the same restriction and more — see its caveat below. This is the reason to prefer the logical form generally: it is the only form every field supports.

Two shorthands are accepted in this form:

A field key may sit alongside a logical block at the root; the two are ANDed. The logical form is the better default for anything a machine generates — it is uniform, and every condition carries its own field name.

Rejected bodies

Malformed conditions return 400 in both root forms — {"all": ["oops"]} and {"name": {"all": ["oops"]}} behave the same way.

Operators

An unrecognized operator is silently treated as eq. It does not return 400. {"op": "like", "field": "display_name", "value": "Acme"} returns 200 with the rows an eq would have matched, so a typo in op reads as a working filter. Check operator spelling against the table above; do not rely on the API to reject one. (contains is the substring operator — there is no like.)

Case sensitivity

The equality and set operators are case-sensitive. The substring operators are not. This catches people out, because the failure is an empty result set rather than an error:

{"op": "eq", "field": "domicile_country_iso_alpha3", "value": "sgp"}

That returns zero rows. "SGP" returns the Singapore-domiciled set.

Two things follow. For eq, ne, in, and nin, match the exact casing the API returns — take values from Reference Data or from a response body rather than typing them by hand. And prefer *_key fields over *_name fields for exact matching: keys are lowercase, underscore-delimited, and contractual, so there is no casing to get wrong. {"op": "eq", "field": "trading_status_key", "value": "trading_status_ceased"} is more robust than the same filter on trading_status_name.

This inconsistency is a known bug, not a design. A future release will make the equality and set operators case-insensitive too, matching the substring operators. A filter that already passes exact casing is unaffected by that change: eq and in would match the same rows, and ne and nin would exclude the same rows. Getting the casing right today is therefore the safe move in both directions — whereas a filter that relies on a case mismatch to exclude something will start behaving differently.

range

value is an array of exactly two elements, low bound first, and both bounds are inclusive. Any other length returns 400 Bad Request.

{"op": "range", "field": "date_founded", "value": ["2015-01-01", "2020-12-31"]}

isnull and notnull

Pass true as the value. {"op": "isnull", "field": "latest_valuation_usd", "value": true} returns rows with no known valuation; notnull returns rows that have one.

The value is ignored. {"op": "isnull", "value": false} still means IS NULL — it does not invert to notnull. Use notnull for the other direction.

Dates

Date and date-time fields take ISO 8601 strings — "2020-01-01" for a date, "2026-08-19T00:00:00Z" for a timestamp — and work with eq, ne, gt, gte, lt, lte, and range.

Nulls and Filters

null means unknown. It is not zero and not false, and it never satisfies a comparison — so rows with a null in the filtered field are excluded from every gt / gte / lt / lte / range filter on that field, in both directions. Filtering {"op": "lt", "field": "total_funding_usd", "value": 1000000} does not return companies whose funding is unknown.

Use isnull when you want the unknowns, and any when you want both:

{"filters": {"any": [
  {"op": "lt",     "field": "total_funding_usd", "value": 1000000},
  {"op": "isnull", "field": "total_funding_usd", "value": true}
]}}

Nullable booleans behave the same way. is_raising_now, is_open_to_co_investment, and the fund classification flags return null when nothing has been declared, which is distinct from false — an {"op": "eq", "value": false} filter returns only the explicit false rows. See Field Types and Nulls.

Keys and Display Names

Most taxonomy concepts are filterable two ways: a *_keys / *_key field taking the stable key, and a *_names / *_name field taking the display label. Filter on the key. Labels can be respelled without the underlying thing changing, which silently re-partitions anything matched on the display string.

{"op": "in", "field": "themes_keys", "value": ["themes_payments", "themes_climate_green_clean"]}

GET /partners/reference-data/?type=enums returns the valid keys for every such field. See Keys and Display Values for the full doctrine, including which fields are the key half of a pair with no _key suffix.

Deal filter fields are the exception — they match on display names only. allocation_type takes "Equity", not "equity", and there is no allocation_type_key filter field. See Capital Receiver Deal Filter Fields below.

Supported Filter Fields

The lists below are the supported filter field names for each endpoint — the contractual surface, and the only names covered by our compatibility guarantees. Build against these.

They are not an exhaustive account of what the filter parser will accept. A name that resolves to an internal database column or relation path is passed through to the query rather than rejected, so an unlisted name can appear to work; it can change or disappear in any release without notice. A name that resolves to nothing returns 400 Bad Request naming the internal columns it tried — that error text is diagnostic output, not a field list to build against.

Field names are per-endpoint. display_name is filterable on capital receivers, capital allocators, funds, and service providers, but the people endpoint has given_name and family_name instead.

Capital Receiver Filter Fields

POST /v3/partners/capital-receivers/

Identity and description — display_name, description, registration_number

Geography — domicile_country_name, domicile_country_iso_alpha3, headquarters_country_name, headquarters_country_iso_alpha3, headquarters_state_name, headquarters_city_name

Categorization — themes_names, themes_keys, horizontals_names, horizontals_keys, techs_names, techs_keys, business_models_names, business_models_keys, industries_codes

Status and attributes — trading_status_name, trading_status_key, is_female_founder, is_raising_now, captable_is_managed, year_founded, date_founded

Funding and financials — total_funding_usd, latest_valuation_usd, latest_investment_stage_name, latest_investment_stage_key, latest_investment_date, latest_operating_revenue_usd, operating_revenue_growth_yoy_pct, financials_latest_financial_year_end

ordering accepts display_name, year_founded, total_funding_usd, latest_valuation_usd, latest_operating_revenue_usd, operating_revenue_growth_yoy_pct, latest_investment_date, created_at, updated_at, last_updated_at.

The funding and financials fields are computed on demand — only when they appear in the filter body or in ordering — so a plain list request pays nothing for them. Filter, ordering, and the response funding object all use the same names. See Common Filter Fields for types and examples. All eight are restricted to the logical form; see the field-keyed form caveat.

financials_latest_financial_year_end is narrower than the rest, and it fails silently. It resolves through a separate lookup against a pre-computed view, which only recognizes a leaf carrying an explicit field key, directly under all, with one of eq, gt, gte, lt, lte. Everything else returns 200 with the condition dropped or misapplied:

Shape	What happens
{"all": [{"op": "gte", "field": "financials_latest_financial_year_end", "value": "2025-01-01"}]}	Applied
{"op": "range", …}, ne, in, nin, isnull, notnull	Dropped — full unfiltered result set, 200
{"financials_latest_financial_year_end": {"op": "gte", …}} (field-keyed)	Dropped — full unfiltered result set, 200
The leaf inside not	Inverted — returns exactly the rows you asked to exclude, 200
The leaf inside any	ANDed — narrower than the any you wrote

Use only eq / gt / gte / lt / lte, only directly under all, and never inside not or any. For a two-sided window, pass gte and lte as two conditions in the same all rather than range.

Capital Allocator Filter Fields

POST /v3/partners/capital-allocators/

Identity and description — display_name, description

Geography — domicile_country_name, domicile_country_iso_alpha3, headquarters_country_name, headquarters_country_iso_alpha3

Allocator type — types_names, types_keys, preferred_allocation_type_name, preferred_allocation_type_key

Stated preferences — preferred_countries_names, preferred_countries_iso_alpha3, preferred_themes_names, preferred_themes_keys, preferred_horizontals_names, preferred_horizontals_keys, preferred_business_models_names, preferred_business_models_keys, preferred_techs_names, preferred_techs_keys, preferred_fund_types_names, preferred_fund_types_keys, preferred_allocation_subtypes_names, preferred_allocation_subtypes_keys, preferred_allocation_deal_types_names, preferred_allocation_deal_types_keys, preferred_industries_codes

Amounts — cheque_size_min, cheque_size_avg, cheque_size_max, dry_powder, median_valuation, current_allocation, target_allocation, stated_count_of_investments

Preference flags — is_open_to_first_time_fund, is_open_to_co_investment, has_preference_for_balanced_funds, has_preference_for_hybrid_funds, has_preference_for_special_situation_funds, has_preference_for_separate_account

ordering accepts display_name, cheque_size_min, cheque_size_avg, cheque_size_max, dry_powder, median_valuation, current_allocation, target_allocation, stated_count_of_investments, created_at, updated_at.

The preferred_* fields are what an allocator states, not what it has done. To segment on actual behavior, compare against actual_allocation_deal_types on the response. Geography resolves through the allocator’s linked legal entity, so allocators backed by a Person return null and are excluded when a country filter is applied.

Fund Filter Fields

POST /v3/partners/funds/

Identity and description — display_name, description, fund_manager_name

Geography — domicile_country_name, domicile_country_iso_alpha3, headquarters_country_name, headquarters_country_iso_alpha3

Vehicle attributes — date_founded, vintage_year, status_name, status_key, structure, term_years

Stated preferences — preferred_countries_names, preferred_countries_iso_alpha3, preferred_themes_names, preferred_themes_keys, preferred_horizontals_names, preferred_horizontals_keys, preferred_business_models_names, preferred_business_models_keys, preferred_techs_names, preferred_techs_keys, preferred_allocation_types_names, preferred_allocation_types_keys, preferred_allocation_subtypes_names, preferred_allocation_subtypes_keys, preferred_allocation_deal_types_names, preferred_allocation_deal_types_keys, preferred_industries_codes

Classification flags — is_first_time_fund, is_raising_now, is_foia_reportable, is_captive_fund, is_single_deal_fund, is_continuation_fund, is_hybrid_fund, is_balanced_fund, is_special_situation_fund

Economics — management_fee_percentage, gp_commitment_percentage, hurdle_percentage, carry_percentage

ordering accepts display_name, vintage_year, term_years, created_at, updated_at.

Note preferred_allocation_types_* here is plural, against preferred_allocation_type_* singular on capital allocators. The classification flags are nullable — null means undeclared, not false.

Person Filter Fields

POST /v3/partners/people/ — given_name, family_name, location_country_name, location_country_iso_alpha3, date_of_birth

ordering accepts family_name, given_name, date_of_birth, created_at, updated_at.

Role and country filtering on people is done with query parameters, not filter-body fields. role_type_key, role_type_name, domicile_country_iso_alpha3, and headquarters_country_iso_alpha3 go on the query string and combine with the body filters. Sending any of them inside filters returns 400 Bad Request. See People.

Person Role Filter Fields

POST /v3/partners/people/roles/ — person_uuid (required, see Batch Endpoints), role_type_key, role_type_name

Service Provider Filter Fields

POST /v3/partners/service-providers/ — display_name, description, legal_entity_uuid, service_type_key, service_type_name

This is the only list endpoint that exposes legal_entity_uuid as a filter field, which makes it the one place you can look a service provider up by the legal entity behind it.

Capital Receiver Deal Filter Fields

POST /v3/partners/capital-receivers/{uuid}/deals/

These fields apply on the per-company endpoint only. The batch POST /v3/partners/capital-receivers/deals/ accepts a filter body but applies nothing beyond its required capital_receiver_uuid IN filter — see Batch Endpoints.

Labels and classification — deal_label, self_declared_label, allocation_type, allocation_subtype, deal_transaction_type

Provenance — date, provenance, description, source

Amounts and shares — deal_size_usd, deal_transaction_size_usd, reported_deal_size_usd, post_money_valuation_usd, no_shares_issued, no_shares_bought, no_shares_sold

These match on display names, not keys — {"op": "eq", "field": "allocation_type", "value": "Equity"}. There is no allocation_type_key filter field; passing one returns 400 Bad Request. Because the values are display names, they are also case-sensitive under eq / ne / in / nin: "equity" returns zero deals.

transaction_label is accepted here and never applied — see Fields Accepted but Not Applied.

Batch Financials Filter Fields

POST /v3/partners/capital-receivers/financials/ — capital_receiver_uuid (required), financial_year_end, uuid

Fields Accepted but Not Applied

A small number of names are accepted by the filter parser and then not applied. The request succeeds with 200 OK and returns a result set wider than the filter implies — there is nothing in the response to indicate the condition was dropped. Do not use these:

If your integration filters on one of these today, its results have never been restricted by that condition. Check the affected queries: the fix is either to drop the condition, or to reproduce it from a field that is applied. transaction_label on deals is the closest to a trap — filter deals with deal_label or self_declared_label instead.

We intend to make each of these return 400 Bad Request rather than pass silently. When that lands, a request using one of these names starts failing outright instead of succeeding with the wrong rows — so treat the list above as work to do now, not later.

These are the field names that never apply. Three other silent-drop cases are shape-dependent rather than name-dependent, and are covered where they arise: an unrecognized op, financials_latest_financial_year_end outside its supported shapes, and any condition beyond the required in on five of the batch endpoints.

Batch Endpoints

The batch endpoints take a required in filter on the parent UUID and return one flat, paginated result set across many parents, so you fetch a sub-resource for a page of entities in one request rather than one request per entity.

curl -X POST https://api.altdmp.io/v3/partners/capital-receivers/deals/ \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "all": [
        {"op": "in", "field": "capital_receiver_uuid", "value": [
          "c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67",
          "fee788ac-cffe-46f0-9bb5-fedb62992bd8"
        ]}
      ]
    }
  }'

Rules, identical on every batch endpoint:

• The in filter is required. Missing or empty returns 400 Bad Request — these endpoints never return unscoped results.
• The in leaf must sit directly inside a root-level all, exactly as shown above. The other body shapes this page documents are not recognized here: {"any": [...]}, a nested {"all": [{"all": [...]}]}, the field-keyed {"capital_receiver_uuid": {"op": "in", "value": [...]}}, and the list shorthand {"capital_receiver_uuid": [...]} each return 400 Bad Request saying the IN filter is missing, even though the UUIDs are right there in the body.
• Maximum 1,000 UUIDs per request. More returns 400, as does any value that is not a valid UUID.
• Every returned row carries the parent UUID field, so you can join it back to the entity it belongs to.
• Pagination is by limit / offset on the query string, as everywhere else. A limit in the body never paginates anything, and on every batch endpoint except POST /people/roles/ it is discarded without a 400 — so a body-only pagination attempt returns the default page size with a 200 and no indication it was dropped. POST /capital-receivers/{uuid}/deals/ behaves the same way. This is unrelated to the Applied / Ignored column above, which is only about extra filter conditions.

On the five endpoints marked “Ignored”, conditions beyond the required in filter have no effect. The request returns 200 and the full row set for the UUIDs you passed. Nothing in the response marks the dropped condition, and an unsupported or misspelled field name does not error either — adding {"op": "eq", "field": "allocation_type", "value": "Equity"} to a batch deals request returns every deal for those companies, equity or not. Filter these results client-side, or call the per-entity endpoint where the fields are honored.

Errors

A rejected filter body returns 400 Bad Request with a message naming the problem — an unsupported ordering value, a range with the wrong number of bounds, a malformed condition, a field name that resolves to nothing, or a batch UUID list that is missing, oversized, or invalid.

Not everything wrong with a filter body is an error. These return 200 with results that do not match what you asked for, and nothing in the response says so:

Test a new filter against a small known result set before wiring it into a sync.

One case keys the message by the parameter at fault rather than using detail — filters passed on the query string. See 400 response bodies for the exact shapes.

Capital Receivers

Last updated: 25 August 2026

Capital receivers are companies and startups that have received investment. This is the most frequently accessed entity type in the Partner API.

Endpoints

List Capital Receivers

Returns a paginated list of capital receiver profiles.

curl "https://api.altdmp.io/v3/partners/capital-receivers/?search=shopback" \
  -H "Authorization: Bearer YOUR_TOKEN"

import requests

BASE = "https://api.altdmp.io/v3/partners"
headers = {"Authorization": "Bearer YOUR_TOKEN"}

resp = requests.get(f"{BASE}/capital-receivers/", params={"search": "shopback"}, headers=headers)
data = resp.json()
# data["results"] is the list, data["count"] is total matches

Example response (ShopBack):

{
  "count": 1,
  "next": null,
  "previous": null,
  "results": [
    {
      "uuid": "c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67",
      "legal_entity": {
        "uuid": "fee788ac-cffe-46f0-9bb5-fedb62992bd8",
        "display_name": "Shopback",
        "description": "ShopBack operates a consumer-facing cashback and rewards platform.",
        "year_founded": 2014,
        "date_founded": "2014-04-01",
        "date_founded_precision": "month",
        "is_female_founder": true,
        "domicile_country": {"iso_alpha3": "SGP", "name": "Singapore"},
        "headquarters": {
          "country_name": "Singapore",
          "country_iso_alpha3": "SGP",
          "state_name": null,
          "city_name": "Singapore"
        },
        "trading_status": {"key": "operating", "name": "Operating"},
        "registration_numbers": [
          {
            "reg_number": "201411189G",
            "authority_type": "UEN",
            "authority_name": "Accounting and Corporate Regulatory Authority"
          }
        ],
        "website_url": "https://www.shopback.sg"
      },
      "captable_source": {"type": "managed"},
      "description": "ShopBack operates a consumer-facing cashback and rewards platform.",
      "themes": [
        {"key": "themes_payments", "name": "Payments"},
        {"key": "themes_business_applications_saas", "name": "Business Applications / SaaS"}
      ],
      "horizontals": [{"key": "horizontals_marketplaces", "name": "Marketplaces"}],
      "techs": [{"key": "techs_fintech", "name": "FinTech"}],
      "business_models": [{"key": "business_models_b2c", "name": "B2C (Business-to-Consumer)"}],
      "industries": [{"code": "0602", "description": "Retail Trade (Except Vehicles)"}],
      "is_raising_now": false,
      "last_updated_at": "2025-10-16T07:33:30Z",
      "funding": {
        "latest_investment_date": "2022-12-13",
        "latest_investment_stage_name": "Series F",
        "latest_investment_stage_key": "series_f",
        "latest_valuation_usd": 925652927.23,
        "latest_valuation_date": "2022-12-13"
      },
      "latest_financials": {
        "financial_year_end": "2025-03-31",
        "operating_revenue_usd": 96318754.34,
        "earnings_before_tax_usd": -12045980.11,
        "liabilities_usd": 184220310.00,
        "operating_revenue_growth_yoy_pct": -2.40,
        "is_audited": true,
        "is_consolidated": false,
        "is_restated": false,
        "audit_opinion": {"key": "audit_opinion_unqualified", "name": "Unqualified Opinion"}
      }
    }
  ]
}

Identity fields live on legal_entity, not on the profile. display_name, year_founded, date_founded, date_founded_precision, domicile_country, headquarters, trading_status, and registration_numbers are all nested under legal_entity — the capital receiver profile itself carries only uuid, description, the classification arrays, captable_source, is_raising_now, last_updated_at, funding, and latest_financials. See Data Model.

funding and latest_financials are null when the company has no deals or no filed financials respectively.

List Query Parameters

is_raising_now is a filter field on the advanced POST filter, not a GET query parameter.

Advanced Filter (POST)

Use POST with a JSON body for complex filters — range queries, multi-value matches, and boolean logic. The body accepts only the filters object; pass search, ordering, limit, and offset as query parameters. filters cannot go the other way — a value in ?filters= returns 400 Bad Request on both GET and POST.

Filter grammar, operators, and the supported filter field list are on the Filtering page. In short: filters must be an object whose top level is all (AND), any (OR), or not (NOT) — wrap even a single condition in all. Blocks nest to any depth. eq, ne, in, and nin are case-sensitive; the substring operators are not. Use the all/any/not form rather than the field-keyed shorthand: the computed funding and financials fields below are only honored in that form.

# Singapore companies at Series B or later
curl -X POST https://api.altdmp.io/v3/partners/capital-receivers/ \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filters": {
      "all": [
        {"op": "eq", "field": "headquarters_country_iso_alpha3", "value": "SGP"},
        {"op": "in", "field": "latest_investment_stage_name",
         "value": ["Series B", "Series C", "Series D", "Series E", "Series F"]}
      ]
    }
  }'

resp = requests.post(
    f"{BASE}/capital-receivers/",
    headers=headers,
    json={
        "filters": {
            "all": [
                {"op": "eq", "field": "headquarters_country_iso_alpha3", "value": "SGP"},
                {"op": "in", "field": "latest_investment_stage_name",
                 "value": ["Series B", "Series C", "Series D", "Series E", "Series F"]},
            ]
        },
    },
    params={"limit": 20, "offset": 0},
)

Common Filter Fields

date_founded filters on the full founding date and supports gte, lte, range, and eq. The response also exposes date_founded_precision ("year", "month", or "day") so you can tell how exact a date_founded value is. year_founded (year only) is retained for backward compatibility; sorting with ?ordering=year_founded is unchanged, though it now orders by the full founding date.

financials_latest_financial_year_end, latest_investment_stage_name, latest_investment_stage_key, latest_investment_date, latest_operating_revenue_usd, operating_revenue_growth_yoy_pct, latest_valuation_usd, and total_funding_usd are computed on demand — only when they appear in the filter body or in ordering — so a plain list request pays nothing for them.

latest_investment_date is the date of a company’s most recent active deal. Sort by it (?ordering=-latest_investment_date) or filter by it (e.g. {"op": "gte", "field": "latest_investment_date", "value": "2026-01-01"}) to pull only recently-funded companies — the v3 equivalent of the v2 date_of_last_round sort. Companies with no deals sort last in both directions.

These field names match the response funding object, so you read, filter, and sort by the same key (e.g. ?ordering=-total_funding_usd).

captable_is_managed: true returns companies with a managed cap table (full transaction-level data available via /captable/ and /investors/); false returns snapshot-only companies. null (no filter) includes both. Companies with no cap table at all are excluded from both eq:true and eq:false queries.

Filter Examples

# Companies that filed financials for FY2023 or later
curl -X POST https://api.altdmp.io/v3/partners/capital-receivers/ \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"filters": {"all": [{"op": "gte", "field": "financials_latest_financial_year_end", "value": "2023-01-01"}]}}'

# Companies with a managed cap table (full transaction-level data available)
curl -X POST https://api.altdmp.io/v3/partners/capital-receivers/ \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"filters": {"all": [{"op": "eq", "field": "captable_is_managed", "value": true}]}}'

# Companies with a snapshot cap table only
curl -X POST https://api.altdmp.io/v3/partners/capital-receivers/ \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"filters": {"all": [{"op": "eq", "field": "captable_is_managed", "value": false}]}}'

# Companies that filed financials for FY2023 or later
resp = requests.post(
    f"{BASE}/capital-receivers/",
    headers=headers,
    json={"filters": {"all": [{"op": "gte", "field": "financials_latest_financial_year_end", "value": "2023-01-01"}]}},
)

# Companies with a managed cap table
resp = requests.post(
    f"{BASE}/capital-receivers/",
    headers=headers,
    json={"filters": {"all": [{"op": "eq", "field": "captable_is_managed", "value": True}]}},
)

Get Capital Receiver Detail

Returns the full profile for a single capital receiver, including additional fields not present in the list response.

curl "https://api.altdmp.io/v3/partners/capital-receivers/c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67/" \
  -H "Authorization: Bearer YOUR_TOKEN"

uuid = "c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67"
detail = requests.get(f"{BASE}/capital-receivers/{uuid}/", headers=headers).json()

The detail response returns every field from the list response except latest_financials, with these differences: legal_entity is the fuller variant (adding alternate_names, website_url, email, phone, founders, directors, auditors), funding is extended with the full equity/debt breakdown, and seven additional top-level fields are present.

{
  "uuid": "c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67",
  "legal_entity": {
    "uuid": "fee788ac-cffe-46f0-9bb5-fedb62992bd8",
    "display_name": "Shopback",
    "description": "ShopBack operates a consumer-facing cashback and rewards platform.",
    "year_founded": 2014,
    "date_founded": "2014-04-01",
    "date_founded_precision": "month",
    "is_female_founder": true,
    "domicile_country": {"iso_alpha3": "SGP", "name": "Singapore"},
    "headquarters": {
      "country_name": "Singapore",
      "country_iso_alpha3": "SGP",
      "state_name": null,
      "city_name": "Singapore"
    },
    "trading_status": {"key": "operating", "name": "Operating"},
    "registration_numbers": [
      {
        "reg_number": "201411189G",
        "authority_type": "UEN",
        "authority_name": "Accounting and Corporate Regulatory Authority"
      }
    ],
    "alternate_names": [
      {"name": "Shopback Pte. Ltd.", "type": "Legal Name", "type_key": "alt_name_legal_name"}
    ],
    "website_url": "https://www.shopback.sg",
    "email": null,
    "phone": null,
    "founders": [
      {"uuid": "f2eac778-a47b-497e-a4c6-ddd71335a404", "name": "Shanru Lai"},
      {"uuid": "9c1d2e3f-4a5b-6c7d-8e9f-0a1b2c3d4e5f", "name": "Henry Chan"}
    ],
    "directors": [
      {"uuid": "1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d", "name": "Willson Cuaca"}
    ],
    "auditors": [
      {"uuid": "ad9be164-4e19-4822-987e-54efe73d8974", "name": "Ernst & Young LLP"}
    ]
  },
  "captable_source": {"type": "managed"},
  "description": "ShopBack operates a consumer-facing cashback and rewards platform.",
  "themes": [{"key": "themes_payments", "name": "Payments"}],
  "horizontals": [{"key": "horizontals_marketplaces", "name": "Marketplaces"}],
  "techs": [{"key": "techs_fintech", "name": "FinTech"}],
  "business_models": [{"key": "business_models_b2c", "name": "B2C (Business-to-Consumer)"}],
  "industries": [{"code": "0602", "description": "Retail Trade (Except Vehicles)"}],
  "is_raising_now": false,
  "last_updated_at": "2025-10-16T07:33:30Z",
  "funding": {
    "latest_investment_date": "2022-12-13",
    "latest_investment_stage_name": "Series F",
    "latest_investment_stage_key": "series_f",
    "latest_valuation_usd": 925652927.23,
    "latest_valuation_date": "2022-12-13",
    "reported_and_filed_equity_usd": 203586016.85,
    "filed_equity_usd": 203586016.85,
    "reported_equity_usd": null,
    "reported_and_filed_debt_usd": null,
    "filed_debt_usd": null,
    "reported_debt_usd": null,
    "total_funding_usd": 203586016.85,
    "latest_investment_amount": 50000000.00
  },
  "financials": [
    {
      "financial_year_end": "2025-03-31",
      "operating_revenue_usd": 96318754.34,
      "earnings_before_tax_usd": -12045980.11,
      "liabilities_usd": 184220310.00,
      "operating_revenue_growth_yoy_pct": -2.40,
      "is_audited": true,
      "is_consolidated": false,
      "is_restated": false,
      "audit_opinion": {"key": "audit_opinion_unqualified", "name": "Unqualified Opinion"}
    }
  ],
  "financial_statements_audited": [
    {
      "year": 2024,
      "date_of_file": "2025-06-30",
      "url": "https://assets.alternatives.pe/assets/file-attachments/996955694181.pdf?Expires=...&Signature=...&Key-Pair-Id=..."
    }
  ],
  "financial_statements_extracted": [
    {
      "year": 2024,
      "date_of_file": null,
      "url": "https://assets.alternatives.pe/assets/file-attachments/08b6d224b06e.pdf?Expires=...&Signature=...&Key-Pair-Id=..."
    }
  ],
  "funding_status": "VC-Funded",
  "has_vc_transactions": true,
  "has_pe_transactions": false,
  "has_ma_transactions": false,
  "has_debt_transactions": false,
  "has_liquidity_events": false,
  "has_distressed_transactions": false,
  "has_partial_exits": true
}

The detail-only fields

The url values are signed and expire one hour after the response. Every request mints a fresh signature, and the Expires parameter in the URL carries the exact deadline as a Unix timestamp — read it rather than hard-coding a lifetime, in case the window changes. Three consequences:

• Download promptly; don’t store the URL. A URL persisted anywhere — a database, a queue, a cached response — is dead within the hour. Re-request the detail endpoint to mint a new one.
• An expired link is not a JSON error. The asset host returns 403 Forbidden with an XML body (<Error><Code>AccessDenied</Code></Error>), not the JSON error shape the rest of the API uses. Handle it separately from an API error response.
• Treat a live URL as a credential. The signature alone authorizes the download — no Authorization header is involved — so anyone holding the link can fetch the document until it expires.

The funding object

Monetary amounts are returned as numbers to two decimal places, or null. Equity and debt are each broken down into filed, reported, and their combined reported-and-filed total:

null funding amounts. A funding amount is null when it is unknown or known to net to zero — these fields never return 0.00. As a result, companies whose funding rolls up to zero sort to the end of funding-based orderings in both directions, and are excluded from numeric range filters (gte/lte, and the total_funding_min/total_funding_max filters), since a null value never satisfies a numeric comparison.

Public-listed companies. Companies classified as public no longer return funding or valuation — every amount in the funding object (and latest_valuation_usd) is null, since a public company has a market capitalization rather than private funding. funding_status is still populated (e.g. "Public Listed").

What counts toward totals. Funding totals count all primary funding across a company’s deals, regardless of deal subtype or type. Secondary transactions are never included.

Cap Table

Returns the current shareholding structure. The shape of the response depends on captable_source.type — always check this field before interpreting results.

curl "https://api.altdmp.io/v3/partners/capital-receivers/c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67/captable/" \
  -H "Authorization: Bearer YOUR_TOKEN"

captable = requests.get(f"{BASE}/capital-receivers/{uuid}/captable/", headers=headers).json()
source_type = captable["captable_source"]["type"]  # "managed" or "snapshot"

Managed Cap Table Response

When captable_source.type is "managed", the cap table is computed from transaction records. Investment amounts and ownership-hierarchy rollups are available.

Every share metric comes in two variants: _absolute is the holding recorded against the shareholder itself, and _aggregate rolls in the holdings of its child_entities (SPVs and other entities it controls). For a shareholder with no children the two are identical.

{
  "count": 4,
  "next": null,
  "previous": null,
  "results": [
    {
      "shareholder": {
        "uuid": "37c44afc-e55e-420c-bb2a-f9225a0d1c8e",
        "name": "East Ventures Fund 2",
        "type_key": "capital_allocator",
        "type": "CapitalAllocatorProfile",
        "allocation_type": "Equity"
      },
      "shares_issued_absolute": 1500000,
      "shares_issued_aggregate": 1500000,
      "shares_bought_secondary_absolute": 0,
      "shares_bought_secondary_aggregate": 0,
      "shares_sold_absolute": 250000,
      "shares_sold_aggregate": 250000,
      "total_invested_usd_absolute": 7500000.0,
      "total_invested_usd_aggregate": 7500000.0,
      "is_held_in_treasury": false,
      "shares_currently_held_absolute": 1250000,
      "shares_currently_held_aggregate": 1250000,
      "percentage_held_absolute": 4.80,
      "percentage_held_aggregate": 4.80,
      "holding_value_usd": 50000000.00,
      "child_entities_count": 0,
      "child_entities": []
    }
  ],
  "captable_source": {"type": "managed"},
  "as_of_date": "2026-08-07",
  "aggregations": {
    "shares_issued_aggregate": 26000000,
    "shares_bought_secondary_aggregate": 0,
    "shares_sold_aggregate": 250000,
    "total_invested_usd_aggregate": 203586016.85,
    "shares_currently_held_aggregate": 26000000,
    "percentage_held_aggregate": 100.00,
    "holding_value_usd": 925652927.23
  }
}

Snapshot Cap Table Response

When captable_source.type is "snapshot", data is sourced from a periodic shareholder register. Investment-amount data is not available.

{
  "count": 12,
  "next": null,
  "previous": null,
  "results": [
    {
      "shareholder": {"uuid": "...", "name": "Temasek Holdings", "type_key": "legal_entity", "type": "LegalEntity"},
      "number_of_shares": 5000000,
      "percentage_held": 35.00000,
      "is_former_shareholder": false,
      "start_date": "2021-03-15",
      "end_date": null
    }
  ],
  "captable_source": {"type": "snapshot"},
  "as_of_date": "2024-12-31",
  "aggregations": null
}

shareholder.type_key here is one of person, legal_entity, shareholder_group, or alt — the last for a register entry recorded only as a name, in which case shareholder.uuid is null. Join on type_key, not on type. aggregations is always null for snapshot cap tables.

percentage_held is a number and a percentage — 35.00000 means 35% of the company. It was a quoted string until 2026-08-14. Note that it carries five decimal places here, where the managed cap table’s percentage_held_absolute / _aggregate carry two.

When the company has no cap table at all — no transactions and no snapshot on file — the response drops the pagination keys entirely and returns just {"captable_source": {...}, "as_of_date": null, "results": [], "aggregations": null}. Read results rather than assuming count is present.

/investors/ returns HTTP 400 for snapshot companies — use /captable/ instead.

Investors

Returns investor-centric aggregates for companies with a managed cap table. Each row represents one investor’s aggregate position.

curl "https://api.altdmp.io/v3/partners/capital-receivers/c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67/investors/" \
  -H "Authorization: Bearer YOUR_TOKEN"

investors = requests.get(f"{BASE}/capital-receivers/{uuid}/investors/", headers=headers).json()

Example response (ShopBack):

{
  "count": 24,
  "next": null,
  "previous": null,
  "results": [
    {
      "uuid": "37c44afc-e55e-420c-bb2a-f9225a0d1c8e",
      "name": "East Ventures Fund 2",
      "investor_type": "fund",
      "registration_numbers": [
        {
          "reg_number": "201411189G",
          "authority_type": "UEN",
          "authority_name": "Accounting and Corporate Regulatory Authority"
        }
      ],
      "first_investment_date": "2019-04-30",
      "latest_investment_date": "2022-03-01",
      "shares_currently_held": 1250000.0,
      "current_share_holding_percentage": 4.8,
      "total_shares_allocated": 1500000.0,
      "total_secondary_shares": 0.0,
      "total_shares_sold": 250000.0,
      "amount_invested_usd": 7500000.0,
      "investment_by_stage_amount_usd": {
        "pre_seed": 0.0,
        "seed": 0.0,
        "series_a": 7500000.0,
        "series_b": 0.0,
        "series_c_and_beyond": 0.0,
        "other": 0.0
      }
    }
  ]
}

An investor row carries either registration_numbers (a list, for legal entities, capital allocators, and funds) or registration_number (a single string, for people) — never both. Check for whichever key is present rather than assuming one.

Deals

Returns funding rounds and individual transactions for a capital receiver. ShopBack, for example, has 25 recorded deals.

curl "https://api.altdmp.io/v3/partners/capital-receivers/c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67/deals/" \
  -H "Authorization: Bearer YOUR_TOKEN"

deals = requests.get(f"{BASE}/capital-receivers/{uuid}/deals/", headers=headers).json()

Example response (ShopBack Series F):

{
  "count": 25,
  "next": "https://api.altdmp.io/v3/partners/capital-receivers/c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67/deals/?limit=20&offset=20",
  "previous": null,
  "results": [
    {
      "uuid": "3869e63e-9b89-4986-9937-b7b21d2a2234",
      "capital_receiver_uuid": "c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67",
      "date": "2022-12-13",
      "investment_quarter": "Q4 2022",
      "first_investment_date": "2022-07-20",
      "last_investment_date": "2023-05-08",
      "self_declared_label": "Series F",
      "allocation_deal_type_name": "Series F",
      "allocation_deal_type_key": "series_f",
      "allocation_type_key": "equity",
      "allocation_type_name": "Equity",
      "allocation_subtype_key": "venture_capital",
      "allocation_subtype_name": "Venture Capital (VC)",
      "share_class": "Ordinary, Series F Preferred",
      "no_shares_issued": 23023201,
      "deal_size_usd": null,
      "reported_deal_size_usd": null,
      "post_money_valuation_usd": 925652927.23,
      "price_per_share_usd": 40.0,
      "description": "ShopBack, Southeast Asia's leading cashback and rewards platform, has closed an $80M Series F round...",
      "headline": "ShopBack Secures $80M in Series F Funding Round",
      "count_of_transactions": 14,
      "transactions": [
        {
          "uuid": "05eaa0d4-a73f-48f7-ad5b-04f0daf918d3",
          "date": "2022-12-13",
          "nature_of_transaction": "Primary",
          "transaction_type": "Series F",
          "allocation_type_key": "equity",
          "allocation_type_name": "Equity",
          "allocation_subtype_key": "venture_capital",
          "allocation_subtype_name": "Venture Capital (VC)",
          "share_class": "Series F Preferred",
          "number_of_shares": 2000000,
          "transaction_size_usd": 80000000.0,
          "price_per_share_usd": 40.0000,
          "buyer": {
            "uuid": "9f8e7d6c-5b4a-3928-1706-f5e4d3c2b1a0",
            "name": "GIC Private Limited",
            "type_key": "legal_entity",
            "type": "LegalEntity",
            "registration_numbers": [
              {
                "reg_number": "198100869P",
                "authority_type": "UEN",
                "authority_name": "Accounting and Corporate Regulatory Authority"
              }
            ]
          },
          "seller": {
            "uuid": "c16a0ffd-4dbb-4f7b-a9ca-a3a47f93be67",
            "name": "Shopback",
            "type_key": "capital_receiver",
            "type": "CapitalReceiverProfile",
            "registration_numbers": [
              {
                "reg_number": "201411189G",
                "authority_type": "UEN",
                "authority_name": "Accounting and Corporate Regulatory Authority"
              }
            ]
          }
        }
      ]
    }
  ]
}

Deal Fields