---
title: "List Datasets"
method: GET
path: "/v3/integrations/{id}/datasets"
tags: ["integrations-v3"]
---

# List Datasets

`GET /v3/integrations/{id}/datasets`

List the datasets an integration instance exposes, most-recently-seen first.

A dataset is one queryable unit of the integration — an index pattern for
Elasticsearch/OpenSearch, an application for AppDynamics, a table for
ServiceNow. Each entry carries when we last saw it and whether data has
arrived for it recently.

Paginated because the count is unbounded in practice: the largest instance
in production owns over 100,000 datasets. Use ``total_count`` for an
"N indexes" label rather than the length of ``datasets``.

``search`` filters server-side on a case-insensitive substring of the
dataset's stored key, narrowing ``total_count`` alongside the page. It does
not match the rendered ``display_name``, which is derived from the stored
details and has no column to filter on; the two coincide for most
integrations but not AppDynamics, whose key holds an application id while
the row displays the application name.

``dataset_term`` narrows to the rows carrying one source-system noun and
narrows ``total_count`` too. It takes a ``key`` from this integration
type's ``dataset_terms`` (see the integration catalog), which is also what
each row reports as ``dataset_term_key`` — never the displayed wording, so
the filter survives a rewording. ``log_group`` returns just the CloudWatch
Logs half of an instance that also holds metric namespaces. A valid key
belonging to another integration type selects nothing, and that empty page
is the honest answer rather than an error. Both filters compose.

**Permissions**: users with integration-setup permission on the owning org.

Returns HTTP 404 if the instance does not exist in the resolved
organization, and HTTP 503 (``DATASET_AVAILABILITY_UNAVAILABLE``) if the
label-value store cannot be reached — availability is unknowable then, and
reporting every dataset as ``not_available`` would be a false statement
about the customer's data rather than about our own reachability.

## Path parameters

- `id` string, required

## Query parameters

- `organization_id` string, nullable
- `page` integer
- `page_size` integer
- `search` string, nullable
- `dataset_term` 'index' | 'region' | 'instance' | 'endpoint' | 'table' | 'application' | 'workspace' | 'service' | 'controller' | 'log_group' | 'namespace' | 'account_group' — A noun one integration's datasets are known by, in the source system. The single identity of a noun: what a variant's ``term`` returns, what keys the selector that filters by it, and the value a client sends to filter by it. Each member carries its own spellings, so a noun cannot exist without them. The enum value is the key rather than the singular, so filtering never depends on display wording and no value needs escaping in a query string.

## Response `200`

Successful Response

- ListDatasetsResponse — One page of an integration instance's datasets.
  - `datasets` DatasetResponse[], required — The requested page of datasets.
    - `id` string, required — Stable UUID for this dataset.
    - `display_name` string, required — Human-readable label for the dataset — the index pattern, application name, endpoint URL or table, depending on the integration. Not guaranteed unique within an instance.
    - `dataset_term_key` string, required — Stable identifier for this dataset's noun, and the value to send back as ``?dataset_term=`` to filter the listing to rows like it. Matches the ``key`` of one of the owning integration type's ``dataset_terms``. Prefer this over ``dataset_term`` for anything machine-read: the wording can change, this cannot. ``dataset`` when the stored details cannot be read, which is the one value not accepted as a filter.
    - `dataset_term` string, required — Display spelling of the same noun — ``index`` for OpenSearch, ``log group`` or ``namespace`` for CloudWatch. For rendering only; filter with ``dataset_term_key``. Matches the ``singular`` of one of the owning integration type's ``dataset_terms``, which is where the plural for counts lives. Only varies within an instance for AppDynamics and CloudWatch; every other integration repeats one noun on every row.
    - `last_checked_at` string, date-time, required — Most recent evidence we have of this dataset: the later of when a population job last confirmed it exists and when data was last observed arriving for it. Not a sortable field — the list is ordered by the former only, so this value is not strictly monotonic down a page.
    - `status` 'available' | 'not_available', required — Whether a dataset has label values in Doris within the freshness window. ``NOT_AVAILABLE`` deliberately conflates "the source is empty" with "no population job has run for it": both present as an absence of Doris rows and telling them apart would need per-dataset job history we do not keep. A dataset's ``last_checked_at`` is the only hint — a months-old value points at the latter.
  - `page` integer, required — 1-based page number this response represents.
  - `page_size` integer, required — Maximum datasets per page.
  - `has_more` boolean, required — Whether a further page exists after this one.
  - `total_count` integer, required — Total datasets the instance owns, independent of paging. Pair with the integration type's ``dataset_terms`` plural for an 'N indices' style count, rather than using the length of ``datasets``.

## Other responses

- `422` — Validation Error

---

[API](https://skmtc.dev/traversal/apis/fastapi.md) · [All operations](https://skmtc.dev/traversal/apis/fastapi/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/traversal/fastapi/revisions/01ca496f3b4f/schema)