Partner API

Last updated: 28 September 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.

The page-size contract is the same on every list endpoint:

A refused value names the parameter at fault rather than using detail:

{
  "limit": ["Must be a positive integer. Omit `limit` to use the default of 20; values above 1000 are reduced to 1000."],
  "status_code": 400
}

Two points worth building around:

• A clamped page is not a silent truncation. When limit=5000 is reduced to 1,000, count still reports the full total and next is returned carrying the applied limit, so a client that pages to exhaustion cannot mistake the first 1,000 rows for the whole result set.
• An empty value is treated as “not specified”. ?limit=&offset= applies the defaults rather than returning 400 — a query string assembled from an unset variable still works.
• Pages never overlap or leave gaps. Every paginated route ends its sort order with a unique key, so rows that tie on the sort field keep one position across requests and paging with limit and offset never skips or repeats one. This holds with or without ordering. See Filtering → Sorting.

Only plain digits are accepted. limit=1_0, limit=+10, and non-ASCII digits are refused rather than reinterpreted.

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.

Unpublished and Deleted Records

The Partner API never shows, counts, or matches a record that is unpublished or deleted, or anything that reaches the API only through one:

• A company, investment firm, fund, person, or service provider that is unpublished or deleted is left out of every list, batch response, and count, and its detail route and every sub-route return 404. A batch request naming its UUID gets no rows, the same as an unknown UUID.
• A transaction whose buyer or seller is hidden is left out of deals, cap tables, commitments, investor totals, and investments pages, and of every figure built from them — share counts, deal sizes, prices, and investment dates.
• A role that is itself unpublished or deleted, or that sits at a hidden organization, is left out of the people routes and never makes a person match a role or country filter.
• Filters never match through a hidden record. A deleted headquarters location reads as no headquarters — it matches no country, and isnull matches it — and fund_manager_name considers only visible managers. On /capital-receivers/, deleted registration numbers and alternate names are not matched by the registration_number filter or search.
• Contact details, websites, auditors, founders, and directors that are unpublished are not shown; the next visible one is, or null.

Two consequences worth designing for:

• Percentages can sum to less than 100%. A cap table or a company’s investor list keeps every visible holder’s percentage of the whole company, and leaves out the hidden ones — see Cap Table.
• A deal can be returned with fewer transactions than it has. The deal stays, even when none of its transactions are visible.

One exception: a company’s own funding figures — the funding object, funding_status, total_funding_usd — and the is_startup classification still count a transaction whose investor is hidden. The company is visible, and the hidden investor is never named.

These rules were applied consistently across every route in September 2026. Before then, some routes still counted or matched hidden records — for example, count on /investors/ could include deleted shareholder groups, and a hidden company’s UUID still returned rows from the batch endpoints.

Incremental Sync

Every capital receiver, capital allocator, fund, person, and service provider carries aggregate_updated_at: the last time the record, or anything shown on it, changed. It includes the record’s own edits, so it is the only field you need to poll to keep a copy of the data current.

To pull what changed since your last sync, filter on it and sort by it together with uuid:

curl -X POST "https://api.altdmp.io/v3/partners/capital-receivers/?ordering=aggregate_updated_at,uuid&limit=1000" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"filters": {"all": [
        {"op": "gte", "field": "aggregate_updated_at", "value": "2026-09-24T00:00:00Z"}
      ]}}'

The same works on /capital-allocators/, /funds/, /people/, and /service-providers/.

• Operators. The field accepts eq, gt, gte, lt, and lte. Any other operator returns 400.
• Values. Send an ISO 8601 date-time with a UTC offset, such as 2026-09-24T00:00:00Z or 2026-09-24T08:00:00+08:00. A date alone, or a time with no offset, returns 400.
• Sorting. ordering=aggregate_updated_at or -aggregate_updated_at. Records with no value yet sort last in either direction, on every one of the five lists.

Page by keyset, not by offset

The value changes while you page. A record edited mid-pull jumps to the end of the list, every record after it moves up one place, and the next offset page silently skips one. So build each next page from the last row of the previous one: take its aggregate_updated_at (V) and uuid (U), and ask for everything after that pair.

{"filters": {"all": [
  {"op": "gte", "field": "aggregate_updated_at", "value": "V"},
  {"any": [
    {"op": "gt", "field": "aggregate_updated_at", "value": "V"},
    {"op": "gt", "field": "uuid", "value": "U"}
  ]}
]}}

Keep ordering=aggregate_updated_at,uuid and offset at 0, and stop when a page returns fewer rows than limit. The uuid half matters: one change can stamp thousands of records with the same instant, so gt on the timestamp alone would skip the rest of them, and gte alone would return the same page forever. A record edited mid-pull reappears near the end with its new value, so de-duplicate by uuid and keep the newest copy.

Start each new pull a few minutes before the highest value you saw last time. Two changes saved at nearly the same moment can become visible in the opposite order to their timestamps, and a small overlap means you never miss the earlier one.

Missed changes are repaired overnight and reach you on your next pull. A nightly check recomputes every value. A record it repairs is stamped with the time of the repair, not the time of the original change, so it lands inside your next window like any other change. A record whose value has not been computed yet has aggregate_updated_at: null, matches no filter on the field, and gets a value from the same check.

What moves it

A change to any of the following, in addition to an edit of the record itself:

It can move without a visible change. Some of these changes are to data the API does not show you, such as a cap-table holding or a transaction whose shareholder or investor is hidden (see Unpublished and Deleted Records). The value still moves, so a pull can return a record whose payload is identical to the copy you already hold. Treat a new value as “something may have changed”, not “the payload is different”.

What does not move it. Renaming shared reference data (a country, city, currency, or classification label) does not bump every record that points at it; pointing a record at a different one does, because that is an edit of the record. Parent and subsidiary relationships, shareholder group membership, a fund’s list of managers, a capital allocator’s types, a service provider’s service types, and a funding round’s own details (as opposed to the transactions in it) do not move it either.

Removals are not reported

aggregate_updated_at covers additions and edits only. A record that is deleted or unpublished simply stops appearing in the lists; it is not re-stamped, so a filter on the field cannot tell you it went. There is no feed of removed records yet. To detect removals, periodically compare the uuid values you hold against a full pull.

last_updated_at is deprecated

last_updated_at is unchanged. It is still the later of when the profile and its registered entity (or, for a capital allocator, the company or person behind it) were last edited, and on people it is the person’s own last edit. It does not move when related data such as financials, transactions, or the cap table changes, cannot be filtered, and can be sorted only on capital receivers, where that sort is slow. Use aggregate_updated_at instead. last_updated_at will be removed in a future release, announced in advance on the Changelog.

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 relabeling 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: 5 October 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 organization 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 organization’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.

What counts as a request

Every HTTP request that reaches the API counts, whatever it returns. A 400, 401, 403, or 404 costs the same as a 200, so a loop retrying a malformed request burns quota as fast as one doing useful work.

What does not affect the count:

• Page size. One request for 1,000 rows and one request for 20 rows each count as one. This is the single largest lever you have — see the checklist below.
• Method. A POST carrying a filters body is a read on this API and counts exactly as a GET does.
• Response size or query cost. There is no weighting by how much work a request does.

The three limits, and which one you hit

Three separate ceilings apply to the same traffic, and the dimension field in the 429 body names the one you reached:

The organization and network ceilings are set well above the per-credential rate, so a single well-behaved integration will not meet them. They exist to bound aggregate load, which has two practical consequences: issuing more credentials does not raise your organization’s total throughput, and parallel workers draw on one shared allowance rather than each getting their own.

The checks run in order — network, then credentials, then organization — and stop at the first refusal. A request refused on one limit may already have counted against a limit it passed on the way, so the figures in the 429 headers describe only the limit that refused it.

The response never reveals which address, user, or organization was counted. dimension tells you the kind of limit, and that is by design.

When you exceed a limit

The API responds 429 Too Many Requests with a JSON body naming the limit that was hit:

{
  "status_code": 429,
  "detail": "Too many requests. Please slow down and retry.",
  "scope": "partner.standard",
  "dimension": "user",
  "retry_after_seconds": 60
}

Four headers accompany it:

Retry-After and X-RateLimit-Reset appear only when a retry time can be determined; the first two are always present on a 429.

X-RateLimit-Reset is a duration, not a Unix timestamp. The name usually means the latter, and treating 60 as an epoch second produces a retry time in 1970 — which typically shows up as a client that retries immediately and stays limited.

Retry-After is a real wait, not a constant. It is the time until the oldest request in the rolling window ages out, so it shrinks as the window drains and is usually shorter than the full 60 seconds. It is never 0 and never longer than the window. Waiting the value you are given is both sufficient and the fastest correct retry.

These four headers appear on 429 responses only. A successful response carries no quota information, so there is no way to read how much capacity is left before you run out. Pace your own sending rather than planning to steer by remaining-quota headers.

Handling a 429

Treat 429 as an expected response on a busy integration, not an error condition. The minimum correct handling is to wait for Retry-After and retry the same request:

import random, time
import requests

def get(url, headers, params=None, max_attempts=5):
    for attempt in range(max_attempts):
        resp = requests.get(url, headers=headers, params=params)
        if resp.status_code != 429:
            resp.raise_for_status()
            return resp.json()
        wait = float(resp.headers.get("Retry-After", 60))
        # Jitter keeps parallel workers from retrying in lockstep.
        time.sleep(wait + random.uniform(0, 1))
    raise RuntimeError(f"Still rate limited after {max_attempts} attempts: {url}")

Three failure modes are worth designing out:

• Retrying immediately. A retry sent before the window frees is refused again and, on the shared ceilings, deepens the hole. Always wait.
• Retrying in lockstep. When several workers hit the limit at once and all wait exactly Retry-After, they resume simultaneously and are refused together. Add a small random delay, as above.
• Treating 429 as fatal. A job that aborts on the first 429 and is then restarted from the beginning re-requests everything it already had, which costs more quota than waiting would have.

If retries keep failing after honoring Retry-After, increase the delay between attempts (exponential backoff with a ceiling) rather than retrying at a fixed interval.

A run with no 429s is not proof you are under the limit. Enforcement can be more permissive than the published rate during infrastructure incidents — limits fail open rather than taking the API down with them. Pace your integration to the published rate; do not calibrate it by pushing until you see a 429.

Staying within the limits

In rough order of how much they buy you:

• Use the largest page size you can. limit=1000 is the maximum on list endpoints. One request for 1,000 rows counts the same against the limit as one request for 20 — a 50× difference in rows per request, for the same quota.
• Use the batch endpoints instead of per-record loops. Deals, financials, news, AUM, and deal share types all have batch POST forms that take a list of UUIDs and return one paginated response. Fetching 500 companies’ deals one call at a time costs 500 requests; the batch form costs a handful. See Batch Endpoints.
• Pull incrementally. Filter each list on aggregate_updated_at from just before your last sync and page by keyset, rather than re-fetching the full set each run. See Incremental Sync.
• Cache what does not change. Reference Data — enum values, countries, industries — changes rarely. Fetch it once per run at most, not once per record.
• Bound your concurrency. Parallel workers share the organization ceiling, so more of them past a point produces 429s rather than throughput. Start with a small fixed pool and raise it only if you are not seeing 429s.
• Spread out bulk work. Page through large result sets steadily rather than issuing requests in tight bursts. A steady 5 requests per second stays comfortably under a 320-per-minute rate; 320 sent in the first two seconds of a minute does not.
• Do not poll for changes you can schedule. Re-running a full sync every few minutes spends most of its quota confirming nothing changed.

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."
}

Some checks key 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
}

And an unsupported limit or offset — see Pagination for the accepted range:

{
  "offset": ["Must be zero or a positive integer. Omit `offset` to start from the beginning of the collection."],
  "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: 25 September 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 organization 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 organization 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: 9 October 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=-aggregate_updated_at

Each endpoint accepts a fixed set of sortable fields. An unsupported ordering value returns 400 Bad Request with the list of valid fields on every list and sub-resource route except four: the people list, /investors/, and both deals endpoints, where it is still ignored — you get 200 in the default order, with nothing saying the sort was dropped. Check the spelling rather than relying on an error there. See Filtering → Sorting for how nulls and ties sort.

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

Company Financials: Funding Rounds

v2 returned per-round data as fundings[] on GET /api/v2/companies/{id}/financials. In v3 each round is a row on GET /v3/partners/capital-receivers/{uuid}/deals/. See Deal Fields.

Capital Providers → Capital Allocators

Fund Performance

Commitment Deals

People Roles

Role data moved off the person record and onto /people/{uuid}/roles/, or the batch POST /v3/partners/people/roles/ for up to 1,000 person UUIDs per request.

role_type is now a nested {key, name} object. role_type_key and role_type_name still exist in v3, but only as filters — query parameters on the people and roles endpoints, and body filter fields on the batch POST /people/roles/ — never as response fields.

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/ (or the batch POST /people/roles/, up to 1,000 person UUIDs per request); read title instead of job_title, and role_type.key / role_type.name instead of role_type_key / role_type_name
• 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: 6 October 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 what happens to a field name an endpoint does not support.

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 computed only 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. 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.

An incomplete condition used to be dropped silently. A leaf one key short of working — no op, or no field — contributed nothing to the query, so the request returned 200 and every row the other conditions allowed. It now returns 400 naming the keys it received. This changed in September 2026. If a saved filter has been quietly returning too many rows, this is a likely cause, and it will now fail loudly instead.

Send booleans as JSON true / false, and dates as valid ISO dates. A string standing in for a boolean is not reliably converted: "yes" and a lowercase "true" both return 400, as does an impossible date such as "2025-13-45". These used to return 500. The startup filters go further and accept only a JSON boolean.

field must be a field name, and a JSON array or object there is not handled cleanly on one endpoint. On /capital-allocators/, {"op": "eq", "field": [], "value": "Acme"} returns 500 rather than a 400; every other endpoint returns 400. Either way the request is malformed — pass the field name as a string. Do not treat the 500 as a retryable server fault.

filters as a JSON string

filters can also arrive as a string holding JSON — the only option in a form-encoded or multipart body. The capital receivers list and every batch endpoint parse it exactly as they parse the object form, so {"filters": "{\"all\": [...]}"} and {"filters": {"all": [...]}} return the same rows. A string that is not valid JSON returns 400. Prefer the object form in a JSON body; the string form exists for clients that cannot send one.

Operators

exact is accepted as an alias for eq, and icontains as an alias for contains. Prefer the names in the table.

An unrecognized operator returns 400. {"op": "like", "field": "display_name", "value": "Acme"} is rejected, and the message lists every operator the field accepts:

{
  "status_code": 400,
  "detail": ["Operator 'like' is not supported for 'display_name'. Supported operators: contains, endswith, eq, gt, gte, in, isnull, lt, lte, ncontains, ne, nin, notnull, range, startswith. Also accepted: exact, icontains."]
}

(contains is the substring operator — there is no like.) This changed in September 2026. Previously an unrecognized operator was silently treated as eq and returned 200, so a typo in op read as a working filter. If you have a filter that has been returning plausible results with a misspelled operator, it will now fail — check your operator spelling against the table above.

Case sensitivity

The substring operators are always case-insensitive. For eq, ne, in, and nin, it depends on the field — and where they are case-sensitive, the failure is an empty result set rather than an error:

{"op": "eq", "field": "themes_names", "value": "fintech"}

That returns zero rows. "FinTech" returns the set tagged with that theme.

These fields match eq, ne, in, and nin case-insensitively:

{"op": "eq", "field": "family_name", "value": "smid"} and "Smid" return the same rows, and so do {"op": "eq", "field": "domicile_country_iso_alpha3", "value": "sgp"} and "SGP".

The multi-value classification fields still require exact casing. Every *_names / *_keys field — themes_names, techs_keys, preferred_countries_names, types_names, service_type_name, and the rest — matches eq, ne, in, and nin exactly as written. A company can carry several themes, and matching those case-insensitively would change what ne and nin mean on them: today {"op": "ne", "field": "themes_names", "value": "Fintech"} returns companies with no Fintech theme, and that meaning is preserved rather than traded for case tolerance. service_type_name on service providers and nationality_name on people behave the same way.

Also case-sensitive: any field that is not text at all — uuid, dates, numbers, and booleans — where casing does not apply.

The safe practice is the same either way: match the casing the API returns. Take values from Reference Data or from a response body rather than typing them by hand. A filter that already passes exact casing keeps working as more fields become case-insensitive; one that relies on a case mismatch to exclude something does not.

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.

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.

They mean “no value recorded”, not strictly “null”. On a text field, a blank value counts as no value recorded, so isnull returns it and notnull does not. This changed in September 2026 — a notnull filter on a text field used to return every row, because a blank was treated as a value. If you have been using notnull on a text field as a way to get the full result set, it will now return fewer rows.

The two are exact complements. For any field, isnull and notnull partition the result set: their counts always sum to the unfiltered total, with no row in both and none in neither.

The value is ignored. {"op": "isnull", "value": false} still means “no value recorded” — 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.

aggregate_updated_at is stricter. It accepts only eq, gt, gte, lt, and lte, and only a date-time with a UTC offset ("2026-09-24T00:00:00Z" or "2026-09-24T08:00:00+08:00"). Anything else returns 400 naming the field:

{
  "status_code": 400,
  "detail": ["'aggregate_updated_at' requires an ISO 8601 date-time with a UTC offset, such as \"2026-09-24T00:00:00Z\"; got '2026-09-24'."]
}

See Incremental Sync for how to page on it.

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 publish both halves — allocation_type takes the display name "Equity", allocation_type_key takes the key — and both match case-insensitively. See Capital Receiver Deal Filter Fields below.

Industry Codes

industries_codes on capital receivers and preferred_industries_codes on capital allocators and funds match along the industry tree rather than as flat values. Codes are 2 digits for a sector, 4 for a group, and 6 for a leaf, and each code starts with its parent’s: 160101 (Hospital Activities) sits under 1601 (Human Health and Social Work Activities), which sits under 16 (Health and Social Care). The full list is the industries section of Reference Data; a code’s parent is its first 2 or 4 digits.

• A code matches itself and everything beneath it. {"op": "eq", "field": "industries_codes", "value": "16"} returns records tagged 16, 1601, or any 16xxxx code.
• A code never matches its parents. 160101 returns records tagged 160101. It does not return a record tagged only 16 or 1601, because that record has not been classified down to hospitals.
• Sending every child of a node is the same as sending the node. All nine 1601xx leaves in one in list are treated as 1601 and, because 1601 is the only group under 16, as 16 — so records tagged only 16 come back too. The same applies to eq, contains, or in conditions on the field grouped in one any. A partial set of children never widens to the parent. When you mean the whole branch, send the parent code.
• Matching is on whole codes. 0101 never matches 030101, which only contains it.
• eq, contains, and in follow these rules, and ne, ncontains, and nin are their exact complement. contains on a code is not a substring match.
• Avoid startswith and endswith on these fields. They compare each code as plain text and ignore the tree: startswith "1601" misses records tagged only 16, which eq "1601" returns, and endswith "0101" matches codes across every sector.
• Only industries shown on the record’s response count toward a match.

{"filters": {"all": [
  {"op": "in", "field": "industries_codes", "value": ["08", "160101"]}
]}}

That returns companies tagged anywhere under sector 08, plus companies tagged Hospital Activities. It does not return a company tagged only 16.

Changed in October 2026. These fields used to match codes flat: eq and in matched only the exact code, and contains was a raw substring match, so "0101" also matched 030101 in another sector. Results move in both directions. A parent code now returns records tagged anywhere beneath it, so expect more rows; a contains that relied on substring matching returns fewer. Re-check saved queries that filter on industry.

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.

The lists are enforced. On the five parent list endpoints, the per-company deals endpoint, the batch endpoints, and /investors/, a field name the endpoint does not support returns 400 Bad Request naming it and listing what that endpoint accepts:

{
  "status_code": 400,
  "detail": ["This endpoint does not filter on 'middle_name'. Supported filter fields: 'date_of_birth', 'family_name', 'given_name', 'location_country_iso_alpha3', 'location_country_name', 'uuid'."]
}

The check reads the whole filter body, so an unsupported name nested under all, any, or not does not get past it, and neither does the field-keyed form — including the scalar shorthand {"middle_name": "Ann"}, which is applied as an equality match when the name is supported. A field named inside a field-keyed condition, or an all / any / not nested under one, is checked too.

The filter surface on the five parent list endpoints is now exactly the list published for each one. Until September 2026 an undocumented name was resolved against internal storage rather than rejected, so a name that was never part of the API — a relation path with __ in it, say — could appear to work. Undocumented names now return 400, including the six the Fields Accepted but Not Applied section said to expect nothing from. Every documented field still filters exactly as before, so a filter body built from the lists below needs no change. If one of yours carries a name that is not in its endpoint’s list, that request now fails instead of quietly returning rows the filter should have excluded — worth checking before your next run. The five are capital receivers, capital allocators, funds, people, and service providers; the batch endpoints and /investors/ already worked this way.

A few legacy spellings kept for older integrations show up in the Supported filter fields: list in that error without appearing below. They are compatibility aliases, not contract — build against the documented name.

The per-company POST /v3/partners/capital-receivers/{uuid}/deals/ enforces its list too, as of September 2026. It was the last permissive endpoint: an unlisted name there filtered on whatever it happened to match, and transaction_label was accepted and ignored. Both now return 400. It accepts exactly the Capital Receiver Deal Filter Fields, the same list as the batch POST /v3/partners/capital-receivers/deals/.

uuid is a filter field on all five list endpoints: the profile’s own UUID on capital receivers, capital allocators, funds, and service providers, and the person UUID on people. With in it re-fetches a known set of records in one request.

aggregate_updated_at is a filter field and an ordering value on all five list endpoints, and so is uuid as an ordering value. Together they are how you pull only what changed since your last sync; see Incremental Sync.

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 — uuid, 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, is_startup, 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

Change tracking: aggregate_updated_at

ordering accepts display_name, year_founded, total_funding_usd, latest_valuation_usd, latest_operating_revenue_usd, operating_revenue_growth_yoy_pct, latest_investment_date, financials_latest_financial_year_end, created_at, updated_at, aggregate_updated_at, uuid, and the deprecated last_updated_at. Without ordering, companies come back in the order they were added to the platform, not by name — send ordering=display_name for A to Z.

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.

is_startup selects startups, or everything else. A company is a startup when it has ever raised venture capital, or when its funding status is Unfunded startup. {"op": "eq", "field": "is_startup", "value": true} returns startups, false returns every other company, and leaving the field out returns every company, as before. It works under all, any, and not, and combines with every other field:

{"filters": {"all": [
  {"op": "in", "field": "domicile_country_iso_alpha3", "value": ["SGP", "MYS", "THA", "IDN", "VNM", "PHL"]},
  {"op": "eq", "field": "is_startup",                  "value": true}
]}}

The value must be a JSON boolean, and the operator eq or ne — "true", 1, null, or any other operator returns 400. It is a filter only; list rows do not carry it. See Startup filters for the full rule and how current it is.

Startup filters

Four endpoints can scope results to startups, all using the same definition of a startup:

A company is a startup when either is true:

• It has ever raised venture capital — a deal with the Venture Capital subtype, or a primary transaction with that subtype. Venture capital is counted only where Alternatives manages the company’s cap table, so a company whose cap table comes from an external source can qualify only through the second rule.
• Its funding status is Unfunded startup: tagged Pre Venture Backed, founded 10 or fewer years ago (or with no known founding date), not listed, not a shell vehicle or a wholly owned or controlled subsidiary, and with no private equity, venture capital, venture debt, or convertible debt.

A company that raised venture capital stays a startup after it lists or takes private equity. A company funded only by venture debt or convertible debt is not a startup.

Classification is updated periodically, not on every change. A company created, published, or newly funded since the last update reads as a non-startup until the next one, so a company that has just raised its first venture round can take a while to appear under true. A company that is unpublished or deleted drops out immediately, whatever the classification says.

On capital receivers and capital allocators, true and false split the result set. Every record matches exactly one of them, and together they return what leaving the filter out returns. The other two split by transaction or by role instead, so one record can match both: an investor in startups and non-startups appears under each with different totals (see Investors → Startup scope), and a person with roles at both kinds of company appears under each (see People → Startup filter).

financials_latest_financial_year_end is narrower than the rest, and it fails silently. It resolves through a separate lookup, 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 — uuid, 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

The seven monetary fields are filtered in whole US dollars, the same unit and the same client-facing names the response and ordering use — pass 1000000, not "1,000,000" or "1m". Use the numeric operators (gt, gte, lt, lte, range, eq, ne); contains and the other substring operators do not apply to them. cheque_size_min / cheque_size_avg / cheque_size_max are three independent values, so a band around a firm’s typical cheque is a filter on cheque_size_avg rather than a range across the min and max fields. As with every numeric field, an allocator that has not stated the figure is null and is excluded from a comparison in both directions — see Nulls and Filters.

{"all": [
  {"op": "gte", "field": "cheque_size_avg", "value": 1000000},
  {"op": "lte", "field": "cheque_size_avg", "value": 10000000},
  {"op": "gt",  "field": "dry_powder",      "value": 50000000}
]}

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

Portfolio — has_startup_investments

Change tracking: aggregate_updated_at

has_startup_investments selects firms that have invested in a startup. true returns firms where GET /capital-allocators/{uuid}/investments/ has at least one row for a startup; false returns every other firm, including firms with no investments at all. That covers the firm’s own equity investments as buyer (or as seller in a secondary), and those of the legal entities below it, the funds it manages, and the legal entities below those funds. Nothing linked to an unpublished or deleted record counts. The value must be a JSON boolean with eq or ne:

{"filters": {"all": [
  {"any": [
    {"op": "in", "field": "headquarters_country_iso_alpha3", "value": ["SGP", "MYS", "THA", "IDN", "AUS", "VNM", "PHL"]},
    {"op": "in", "field": "domicile_country_iso_alpha3",     "value": ["SGP", "MYS", "THA", "IDN", "AUS", "VNM", "PHL"]}
  ]},
  {"op": "eq", "field": "has_startup_investments", "value": true}
]}}

It is a filter only, and there is no query-parameter form, since this list takes filters from the body alone.

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, aggregate_updated_at, uuid. The default is display_name ascending.

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 — uuid, 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

Change tracking: aggregate_updated_at

ordering accepts display_name, vintage_year, term_years, created_at, updated_at, aggregate_updated_at, uuid. The default is display_name ascending.

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.

fund_manager_name asks about the fund’s visible managers, one condition at a time. A fund can have several managers. Each fund_manager_name condition asks “does some manager match?” — or for ne, nin, ncontains, and not, “does no manager match?” — and managers that are unpublished or deleted are never considered. Two consequences:

• all of two fund_manager_name conditions matches a fund whose managers meet one each. {"all": [{"op": "eq", "field": "fund_manager_name", "value": "Alpha Capital"}, {"op": "eq", "field": "fund_manager_name", "value": "Beta Partners"}]} returns funds co-managed by both. Until September 2026 it required a single manager to meet both conditions, so it never matched anything.
• isnull matches a fund with no visible manager, and notnull one with at least one. search on the funds list does not match a hidden manager’s name either.

Person Filter Fields

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

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

Role, country, and startup filtering on people is done with query parameters, not filter-body fields. role_type_key, role_type_name, domicile_country_iso_alpha3, headquarters_country_iso_alpha3, and organization_is_startup 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. organization_is_startup is accepted on the query string — see People → Startup filter.

Service Provider Filter Fields

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

ordering accepts display_name, created_at, updated_at, aggregate_updated_at, uuid. The default is display_name ascending, and an unrecognized value returns 400 Bad Request listing them.

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.

ordering=display_name replaced a relation-path value in September 2026. This endpoint previously accepted only legal_entity__display_name, and ignored anything it did not recognize. display_name is now the name to send; the old value returns 400.

Capital Receiver Deal Filter Fields

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

These fields apply on the batch POST /v3/partners/capital-receivers/deals/ too, alongside capital_receiver_uuid. Both endpoints return 400 for any other name, transaction_label included. The batch endpoint additionally enforces a date lower bound on market-wide queries — see Batch Deals.

Labels and classification — deal_label, self_declared_label, allocation_type, allocation_subtype, deal_transaction_type, and the matching key fields allocation_type_key, allocation_subtype_key, deal_transaction_type_key

Provenance — date, provenance, provenance_key, description, source

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

Prefer the *_key fields for classification and provenance. allocation_type, allocation_subtype, deal_transaction_type, and provenance match on display names, which can be reworded; the key fields take the stable key exactly as it appears in a deal response or in Reference Data. Casing is not the deciding factor here — all eight of these match case-insensitively under eq / ne / in / nin, so "equity" and "Equity" return the same deals — but a display name is presentation text and a key is contractual.

Three fields carry a round size, and they are not interchangeable:

{"op": "gte", "field": "deal_size_usd", "value": 1000000} silently excludes every Reported deal, because those are null in that field. Use total_deal_size_usd unless the source of the figure is part of what you are asking for.

deal_transaction_size_usd filters and sorts but has no response field of the same name — you cannot read back the value you matched on. no_shares_bought and no_shares_sold are returned on the deal row, and a filter or sort on either matches the value shown there.

The three share fields count equity transactions only; shares recorded on a debt transaction, such as a conversion or refinancing leg, are left out. The share fields and the size fields are also computed without any transaction whose buyer or seller is unpublished or deleted, so a filter or sort never selects a deal because of a party the response does not show.

Sorting deals

Both deals endpoints accept these on ?ordering=, with a - prefix for descending. The default is -date.

date, total_deal_size_usd, deal_size_usd, reported_deal_size_usd, deal_transaction_size_usd, post_money_valuation_usd, provenance, no_shares_issued, no_shares_bought, no_shares_sold

The size fields sort the way they filter. ?ordering=-total_deal_size_usd ranks every deal together; ?ordering=-deal_size_usd ranks only the non-Reported ones and pushes the rest to the end, since they hold null there.

Any other value returns 400 Bad Request naming the keys above. Before 2026-09-30 these endpoints ignored an unrecognized value and returned 200 in -date order; see Sorting.

Batch Financials Filter Fields

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

Fields Accepted but Not Applied

No field name is accepted and then ignored any more. Every endpoint returns 400 Bad Request for a name it does not apply.

Seven names left this list in September 2026 and now return 400 naming the field:

• transaction_label on the per-company POST /v3/partners/capital-receivers/{uuid}/deals/. Filter deals with deal_label or self_declared_label instead.
• funding_status and has_vc_transactions on capital receivers. Both are returned on the funding object, so that test can be applied to the rows you get back — and for the most common reason to want them, use is_startup.
• nationality_name, nationality_iso_alpha3, is_employee, and associated_ca_types on people. Nationality and employment status are not part of the people endpoint.

None of the seven ever filtered anything, so no working filter changed — the endpoints now say so instead of accepting the condition and ignoring it.

One silent-drop case remains, and it is shape-dependent rather than name-dependent: financials_latest_financial_year_end outside its supported shapes. Four other cases have left this section — an unrecognized op, an incomplete condition, any unsupported condition on a batch endpoint, and the seven names above all now return 400.

Batch Endpoints

The batch endpoints take an 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.

Each one accepts a fixed set of filter fields and returns 400 for anything else. The sets are not uniform, because the endpoints are not:

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, on every batch endpoint except POST /capital-receivers/deals/:

• 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.

And on all of them, batch deals included:

• 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 returns 400 — only filters may be sent there. POST /capital-receivers/{uuid}/deals/ behaves the same way:

  {
    "status_code": 400,
    "detail": ["Unrecognized field(s) in request body: limit. Only filters may be sent in the body; pass limit, offset and ordering as query parameters."]
  }
  

• A filter field the endpoint does not accept returns 400, and the message names it and lists what is supported. This includes a misspelled parent UUID field — capital_receiver_uui no longer behaves like capital_receiver_uuid:

  {
    "status_code": 400,
    "detail": ["This endpoint does not filter on 'date'. Supported filter fields: 'capital_receiver_uuid'."]
  }
  

  The check reads the whole filter body, so nesting an unsupported field under any or not, or writing it in the field-keyed form, does not get it past.

Both of these used to pass silently, and that is the change most likely to break an existing integration. A condition beyond the required in was accepted and dropped: asking for “news for these 500 companies, but only since January” returned every news row for all 500, with a 200 and nothing marking the discarded condition. A body limit was ignored the same way, returning the default page size. Both now fail loudly. If you send extra conditions on any of the four endpoints whose “Other fields accepted” is None, those requests start returning 400 — drop the conditions and filter client-side, or call the per-entity endpoint where the fields are honored.

Batch Deals: filtering and ordering

This is the one batch endpoint with a real filter surface, and the only one where the parent UUID is optional.

capital_receiver_uuid is optional. A date filter on its own is a valid query, returning deals across every company on the platform:

{"filters": {"all": [{"op": "gte", "field": "date", "value": "2025-01-01"}]}}

A market-wide query must carry a date lower bound. With no capital_receiver_uuid, the request needs a date condition using eq, in, gt, gte, or range — something that puts a floor under the result set. lt, lte, and ne bound only the upper side and do not qualify. A request with neither company UUIDs nor a lower bound returns 400.

The bound has to hold for every row the filter can return, which is stricter than “a lower bound appears somewhere in the body”:

Ordering is by deal date, most recent first, by default. Pass any key from Sorting deals on the query string, such as ?ordering=-total_deal_size_usd; anything else returns 400. Results carry a stable secondary sort, so paging through a large market-wide set does not repeat or skip rows between pages.

The other deal filter fields apply here too — the same set as the per-company endpoint, listed under Capital Receiver Deal Filter Fields, plus capital_receiver_uuid.

On top of the rules above, these return 400 here:

• A substring operator on date — contains, startswith, endswith and their negations. {"op": "contains", "field": "date", "value": "2025"} used to return a plausible-looking set that was not the query you meant. Use the comparison operators.
• A non-ISO date, a range that is not exactly two ISO dates, or an in / nin on date that is not a list of ISO dates.
• More than 1,000 capital_receiver_uuid values, or a malformed one, wherever in the filter tree they sit — nesting them inside an any no longer evades the cap.
• A node carrying two of all / any / not, or one of them beside an op / field condition. Only the first was ever applied, so a body narrowing to one company via a top-level any returned every company with a 200. Nest them instead: {"all": [<condition>, {"any": [<condition>]}]}.

A date under any or not filters, but does not scope. The lower-bound check reads the logical structure, so placement decides whether a market-wide query is allowed — see the table above. Keep the bound in the top-level all and it always counts.

Sorting

ordering is a query parameter on every list and sub-resource route that returns more than one row. Pass a field name for ascending, or prefix it with - for descending. Each endpoint page lists the values its routes accept.

An unrecognized value returns 400 Bad Request naming the values the route accepts:

{
  "status_code": 400,
  "detail": ["Invalid ordering field 'bogus'. Valid ordering fields are: date, dpi, irr, irr_pct, net_multiple, rvpi."]
}

A route whose order is fixed returns 400 for any ordering, even a value that matches its own order, such as -date on batch news:

{
  "status_code": 400,
  "detail": ["This endpoint returns rows in a fixed order and does not accept `ordering`. Remove the parameter."]
}

Those routes are both cap tables, every financials/ route, the company investors/ route, person roles/, reference-data/, and the batch aum/, news/, deal-share-types/, performance/, and roles/ routes. Each endpoint page says so. On a route for one record, an unknown UUID still returns 404 first.

The same rules hold on every route that sorts:

• Rows with no value sort last, in either direction. -irr puts funds with no IRR at the end, not the start. The people list is the exception: only aggregate_updated_at sorts this way there.
• An empty ?ordering= applies the route’s default, the same as leaving the parameter out.
• Ties keep one fixed order. Every route breaks ties with a unique final key, so paging with limit and offset never skips or repeats a row, even when many rows share the sort value, as long as the rows do not change while you page. When you sort by a value that can change mid-pull, such as aggregate_updated_at, page by keyset instead; see Incremental Sync.

These rules took effect across the sub-resource routes in September 2026. Before then, the AUM, news, commitments, fund performance, and investments routes differed: several returned 500 for an unknown value, two silently fell back to -date, the investments pages ignored ordering altogether, and ties came back in no guaranteed order. Two changes can move rows you already fetch: commitments with no date now come last under the default -date rather than first, and on fund performance a descending sort now puts null values last. If you page through a route and de-duplicate by UUID to cope with repeats, that is no longer needed.

Errors

A rejected filter body returns 400 Bad Request with a message naming the problem — a range with the wrong number of bounds, a malformed condition, a filter field name the endpoint does not support, or a batch UUID list that is missing, oversized, or invalid. An unsupported ordering value returns 400 on every route, as does any ordering on a route whose order is fixed; see Sorting.

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:

Three entries left this table in September 2026 and now return 400: an unrecognized op, any condition beyond the required in on a batch endpoint, and any filter field name outside an endpoint’s supported list, including the seven that used to be accepted and dropped.

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: 5 October 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",
      "aggregate_updated_at": "2026-09-24T03:12:45.118204Z",
      "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, aggregate_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 match case-insensitively on this endpoint’s single-valued text fields — display_name, description, the geography fields, trading_status_*, and latest_investment_stage_* — and case-sensitively on the multi-value themes_*, horizontals_*, techs_*, and business_models_* fields; the substring operators are case-insensitive everywhere, and an unrecognized op returns 400 Bad Request. 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.