Querying objects

List and filter objects. All list endpoints — standalone, related, aggregations, distinct, and search — share the same filter, paging, and sort parameters, and every list response uses the same DataObjectPage shape.

List / query

GET /data/{tenant}/{typeName}

Returns a paged, filtered, sorted list of objects of a type (identified by its plural REST name — see TypeFQN to URL mapping). By default the result includes objects of typeName and all its subtypes.

Filtering

Any query parameter that is not a reserved word (page, size, sort) is interpreted as a filter on a field or a relation. The operator is encoded as a suffix on the parameter name; a bare field=value means equality. Multiple filters are combined with AND.

Parameter form	Operator	Applies to	Meaning
field=value	equals	value field, relation	Field equals value; for a relation, the related object's name equals value.
relation.name=value	equals	relation	Explicitly match a relation by the related object's name.
field_from=value	≥ (range start)	value field	Lower bound. Combine with _to for a closed range.
field_to=value	≤ (range end)	value field	Upper bound.
field_startswith=value	starts-with	value field, relation	Prefix match on the field, or on a relation's name.
field_notempty	is not empty	value field	The field has a value.
field= (empty value)	is empty	value field	The field has no value.
relation_href=value	equals (by id)	relation	Match a relation by the related object's URI/UUID (exact id) rather than by name.
q=value	full-text	whole object	Full-text search across the object; switches the query to the search index. See Global search.
type=name,name	—	—	Include additional subtypes in the result set.

Notes:

• Operator availability is data-type dependent. Filters and ranges only apply to fields whose data type is stored in the SQL index. Types that are not SQL-indexed — LONGTEXT, JSON, SECRET, ARRAY — cannot be filtered, sorted, or aggregated on, and filter parameters targeting them are silently ignored. Range operators (_from / _to) likewise require an indexed, order­able type. See Value Data Types.
• _from and _to for the same field are merged into a single range.
• Unknown field/relation names in filter parameters are ignored rather than rejected.

The q parameter

q is different from the field filters above: it runs against the full-text index, not the SQL store. When q is present the whole request is served from the search index, and:

• It matches across a single combined field built from all of the object's search-indexed value fields (everything except LONGTEXT, JSON, SECRET, FILE, IMAGE) — you cannot target an individual field with q.
• The value is treated as a prefix query (term*); multiple terms are combined with AND (all must match).
• q does not combine with structured filters. On the search path only tenant scoping and the type/subtype scope apply — any field=..., range, or relation filters on the same request are ignored. Use structured filters or q, not both.

For a standalone full-text endpoint across multiple types, see Global search.

Paging

List endpoints accept Spring-style paging parameters:

Parameter	Default	Description
page	0	Zero-based page number.
size	20	Page size.

Paging is cursor-style, not counted: the server fetches one extra row to decide whether a further page exists, and advertises it through a next link. No total element or total page count is returned for standard queries — use the _links to navigate, or the aggregations endpoint's total for a total.

Sorting

?sort=field
?sort=field,desc

Sort by a value field or a relation (by related-object name). Ascending is the default; append ,desc for descending. sort is a reserved parameter and is never treated as a filter.

Response: DataObjectPage

List responses are HAL-style JSON: the objects live under _embedded, keyed by the plural REST type name, and navigation links under _links.

{
  "_embedded": {
    "companies": [
      { /* a DataObject — see below */ }
    ]
  },
  "_links": {
    "self":  { "href": "/data/2f9c6e1a-7b34-4d58-9c21-0a5e8f1b2c3d/companies?page=0" },
    "next":  { "href": "/data/2f9c6e1a-7b34-4d58-9c21-0a5e8f1b2c3d/companies?page=1" },
    "excel": { "href": "/data/2f9c6e1a-7b34-4d58-9c21-0a5e8f1b2c3d/excel/companies" }
  }
}

• first and prev links appear only when not on the first page; next only when a further page exists.
• excel (an export link carrying the same filters) is present for non-system types.
• Filter, sort, and size parameters are preserved in every link.

DataObject shape

Each embedded object — and the single-object response from GET {typeName}/{id} — has the same shape: timestamps, then one property per non-hidden value field, a _types list, and a _links block for relations and metadata.

{
  "creationDate": "2026-01-15T09:30:00Z",
  "modificationDate": "2026-02-01T14:12:00Z",

  "name": "Acme B.V.",
  "revenue": 1250000.00,

  "_types": ["company", "entity", "item"],

  "_links": {
    "self":    { "href": "/data/2f9c6e1a-7b34-4d58-9c21-0a5e8f1b2c3d/companies/{id}" },
    "scripts": { "href": "/scripts/2f9c6e1a-7b34-4d58-9c21-0a5e8f1b2c3d/companies/{id}/scripts" },

    "country": { "href": "/data/2f9c6e1a-7b34-4d58-9c21-0a5e8f1b2c3d/countries/{id}", "name": "Netherlands" },

    "employees": {
      "href": "/data/2f9c6e1a-7b34-4d58-9c21-0a5e8f1b2c3d/companies/{id}/employees",
      "values": [
        { "href": "/data/2f9c6e1a-7b34-4d58-9c21-0a5e8f1b2c3d/people/{id}", "name": "Alice Johnson" }
      ]
    },

    "metadata": { "href": "/metadata/2f9c6e1a-7b34-4d58-9c21-0a5e8f1b2c3d/dataObject?types=companies" }
  }
}

• Value fields are emitted by name as their JSON value (see JSON Representation). FILE/IMAGE fields become an object with contentType, fileName, size, and a href download link. History-enabled fields become { "current": ..., "history": [...] }. SECRET and hidden fields are omitted.
• _types lists the singular REST names of every type in the object's inheritance chain.
• Single-valued relations appear in _links keyed by the singular relation name, each with the related object's href and name.
• Multi-valued relations appear keyed by the plural target type name, with a href to the related-list sub-resource and an inline values array of { href, name } for the current links.
• metadata / relatedDataObject / form links point at the Metadata API descriptions for rendering.

Related list

GET /data/{tenant}/{relatedTypeName}/{relatedId}/{typeName}

Returns the objects of typeName related to the given relatedTypeName/relatedId object — the sub-resource form used by RELATED_VIEW layouts. It accepts the same filter, paging, and sort parameters as the standalone list, scoped to the relation. Links in the response (including next and excel) keep the related-list path shape.

Distinct values

GET /data/{tenant}/{typeName}/distinct?distinct={fieldOrRelation}
GET /data/{tenant}/{relatedTypeName}/{relatedId}/{typeName}/distinct?distinct={fieldOrRelation}

Returns each distinct value of a field or relation over the filtered set, with a count — used to populate filter dropdowns. The target must be SQL-indexed; other filter parameters narrow the set the distinct values are computed over.

Every entry has the uniform shape { "value": …, "count": … }:

• For a value field, value is the field value itself (a string, number, or date JSON).
• For a relation, value is a { "name", "href" } object identifying the related object; the related object with value: null is the bucket counting objects that have no such relation.
• By default entries are ordered by value ascending. sort=count (or sort=count,desc) instead orders by frequency.

{
  "values": [
    { "value": { "name": "Dossier A", "href": "/data/2f9c6e1a-7b34-4d58-9c21-0a5e8f1b2c3d/dossiers/{id}" }, "count": 12 },
    { "value": "/draft documents/may 2020", "count": 3 }
  ]
}

Field values

GET /data/{tenant}/{typeName}/values/{fieldName}

Both return a flat array of DataValue items — the field's value plus the owning object's URI:

[
  { "value": "Netherlands", "link": "/data/2f9c6e1a-7b34-4d58-9c21-0a5e8f1b2c3d/companies/{id}" }
]

There is one entry per object that has a value for the field; the results are not de-duplicated. The two paths differ only in scope:

Path	Scope
{typeName}/values/{fieldName}	Same, but the filter parameters narrow which objects contribute.