> ## Documentation Index
> Fetch the complete documentation index at: https://developers.dealroom.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Known limitations

> Endpoints and filters that the Dealroom API exposes but are not fully functional today. Read before relying on them in production code.

The OpenAPI spec advertises every endpoint and filter the API understands.
A subset of those is **not fully functional today** — either the backing
table is not loaded from BigQuery, the backing column is always `NULL`, or
the endpoint returns introspection data instead of the data its name
implies. This page lists every known case so you can plan around them.

<Note>
  Each item below also surfaces in the [API Reference](/api-reference) as a
  warning blockquote at the top of the affected operation and as an
  `x-data-status` extension on the operation. The
  [Filters & Sorting reference](/mintlify/references/filters-and-sorting)
  flags affected filters with a `⚠ no data` status column and an inline
  `<Warning>` callout.
</Note>

## Endpoints

### Ecosystems and landscapes — `unloaded`

The `ecosystems`, `landscapes`, and `landscape_entities` tables are
user-owned. They are **not populated by the BigQuery loader**, so a
freshly deployed environment has no rows until a caller creates them
through the API.

Affected operations:

* `GET /api/platform/ecosystems`
* `GET /api/platform/ecosystems/{id}`
* `POST /api/platform/ecosystems`
* `PATCH /api/platform/ecosystems/{id}`
* `DELETE /api/platform/ecosystems/{id}`
* `GET /api/platform/ecosystems/{id}/landscapes`
* `POST /api/platform/ecosystems/{id}/landscapes`
* `PATCH /api/reference/landscapes/{id}`
* `DELETE /api/reference/landscapes/{id}`
* `PUT /api/reference/landscapes/{id}/entities`

<Warning>
  Treat ecosystems and landscapes as user-owned scratch space, not a curated
  dataset. Data written through the API does not flow back to BigQuery, will not
  survive a full reseed, and is not shared across environments.
</Warning>

### `GET /api/system/metrics` — `stub`

Returns the server's observability configuration (OpenTelemetry endpoint,
service name, instrumentation list, exported metric names). It is **not**
a metric data source. For actual measurements use:

* **API usage / billing:** `GET /api/platform/usage/*`
* **Infrastructure metrics:** Prometheus / Grafana (oncall dashboards)
* **Tracing:** Sentry

### `GET /api/data/jobs` — sparse fields unexposed — `data-incomplete`

The jobs dataset covers **active openings only**. Five columns are loaded but
**not exposed or filterable** because they have under 1% coverage (Predict
Leads, which supplies most job volume, does not provide them): `salary_min`,
`salary_max`, `currency`, `department`, and `contract_type`. The endpoint
returns the well-populated fields (title, source, location, `date_posted`) plus
the joined hiring company.

## Filters

### Investor fund-field filters — `data-incomplete`

Five filters on the investor scope are registered and accept input, but
the underlying columns are loaded as `CAST(NULL AS …)` placeholders. Every
query that constrains on them returns zero rows.

| Filter key                | Backing column                     |
| ------------------------- | ---------------------------------- |
| `total_investments_count` | `entities.total_investments_count` |
| `fund_size`               | `entities.fund_size_usd`           |
| `vintage_year`            | `entities.vintage_year`            |
| `is_raising`              | `entities.is_raising`              |
| `fund_status`             | `entities.fund_status`             |

<Warning>
  Treat these as unavailable until a BigQuery source is wired up. The Filters &
  Sorting reference flags them with `⚠ no data` in the Status column.
</Warning>

## Partial / known gaps

In addition to the unimplemented filters above, \~56 company-scope filters
from the legacy V2 API are tracked as "Truly Missing" — for example
`revenue_min`/`_max`, `last_funding_valuation_min`/`_max`,
`has_website_url`, `website_inactive`, `has_address`, `tech_stack`,
`founders_age`, `has_app_downloads_chart`. They are not registered today
and any reference to them in older code or queries will return a
`400 unknown_filter` error.

Founder employer-relationship filters (`companies_positions`,
`companies_income_streams`, `companies_client_focus`,
`companies_technologies`) are similarly not wired up.

The Exits / IPOs surface is partial — only `is_exited` is queryable.
Exit details (`exit_type`, `exit_amount`, `exit_year`, `exit_valuation`)
are not exposed and there is no dedicated `/api/exits` endpoint.

## How to detect a gap programmatically

If you're generating an SDK from the OpenAPI spec, look for the
`x-data-status` extension on operations and the `data_status` metadata
returned by `GET /api/reference/filters?scope={scope}` for filters. Both fields
carry a `kind` (`stub` / `data-incomplete` / `unloaded` / `partial`) and
a human-readable reason.