Skip to content

Lineage queries

A lineage field stores values that form a hierarchy. For example, if B.1.1 is a sub-lineage of B.1, then a query for B.1* can include records assigned to B.1, B.1.1, B.1.1.7, and other descendants.

Without a wildcard, lineage filters match only the exact lineage value:

GET /sample/aggregated?lineageField=B.1.1

This returns records whose lineage field value is exactly B.1.1.

To include sub-lineages, add * at the end of the lineage:

GET /sample/aggregated?lineageField=B.1.1*

B.1.1* and B.1.1.* are equivalent. Both match B.1.1 itself and descendants such as B.1.1.7.

The * suffix above includes descendants when filtering. The includeSublineagesFor parameter is the aggregation counterpart: it groups the /sample/aggregated results by a lineage field so that each lineage’s count includes the sequences assigned to that lineage or any of its sublineages.

Name the lineage field to expand with includeSublineagesFor, and list that same field in fields:

GET /sample/aggregated?fields=lineageField&includeSublineagesFor=lineageField

In a POST request:

{
"fields": [
"lineageField"
],
"includeSublineagesFor": "lineageField"
}

The response contains one row per lineage defined for that field, including lineages that have a count of zero. This makes the result well-suited to building lineage facets, where you want every possible lineage listed even if no sequence currently matches.

Lineage-indexed fields can also be used in advanced queries:

GET /sample/aggregated?advancedQuery=lineageField=B.1.1*

In POST requests, use the same expression as the advancedQuery value:

{
"advancedQuery": "lineageField=B.1.1*"
}