List All Ingestion Assets

• Get a global view of all uploaded files.
• Monitor asset processing across multiple ingestions.

Use filter[field]=condition:value to narrow results. See Query Parameters for full syntax.

• filter[assets.task_id]=eq:<uuid> — scope to a specific ingestion task
• filter[tags]=eq:verified — filter by tag name
• filter[source_file]=eq:locations.csv — filter by original file name
• filter[normalised_data.id]=eq:<uuid> — filter by normalised location ID
• filter[normalised_data.commodity_type]=eq:timber — filter by commodity
• filter[assets.data.CITY]=eq:London — filter by source data fields using dot-notation
• filter[assets.data.ASSET_NAME]=contains:Aberdeen — substring match on source data
• filter[compliance]=eq:non_compliant — filter by per-location EUDR deforestation status (non_compliant / pending / compliant / excluded / not_assessed); see Deforestation roll-up below

Add include=deforestation (or ?deforestation=<view>) to attach a per-location EUDR deforestation roll-up under attributes.deforestation on each item — the compliance summary for that item's location_id:

GET /ingestions/assets?include=deforestation

"deforestation": {
  "total_plots": 12, "compliant_plots": 9, "non_compliant_plots": 2,
  "unknown_plots": 1, "total_area_ha": 84.3, "compliant_area_ha": 61.0
}

A facility/shed aggregates its whole catchment; a plot location rolls up the parts of its latest upload. Facility/shed roll-ups are read from a cache written at task completion (no live catchment scan); plot verdicts are computed live.

Pick the variant with ?deforestation= (also enables the block):

• ccdc — CCDC (continuous change detection) metrics only
• eudr — EUDR monitoring-window metrics only
• true / user (or omit) — org default: prioritised fallback (prefer a variant with an assessed metric, then CCDC, then EUDR window)

Filter the list to a status with filter[compliance]=eq:non_compliant|pending|compliant|excluded|not_assessed — same vocabulary as the task-level filter[compliance] on GET /ingestions, evaluated per location against the selected variant. meta.total reflects the filter. See Query Parameters → EUDR compliance verdict.

Upload the same facility three times and this endpoint returns it three times, because each upload is its own record. Every row says where it sits in that history.

On a per-record row (facility, shed, or an unfolded plot):

"attributes": {
  "asset_task_id": "<this row's task>",
  "superseded_count": 2,
  "asset_task_ids": ["<this task>", "<the one before>", "<the first>"]
},
"links": {
  "superseded": "/ingestions/assets?filter[location_id]=eq:<location_id>&filter[organization_id]=eq:<org_id>"
}

Following links.superseded returns superseded_count + 1 rows — the record and its predecessors. It carries both filters deliberately: superseded_count counts one (organization, location) pair, so without the org a parent whose two children hold the same location would get both children's records back and the listing would disagree with the count.

superseded_count counts the whole history, not the one generation directly before it. Re-election points every dead record in a group at the live one, so a location uploaded three times gives the survivor 2, not 1.

The count also ignores the request's other filters, for the same reason the link is org-scoped: a filter[status] that excludes the predecessors does not change it, so the number and the link always describe the same group.

A row with no resolved location has no group, so it gets no links.superseded (its superseded_count is 0).

"relationships": {
  "superseded": {
    "data": [
      { "id": "<row_id>", "asset_task_id": "…", "source_file": "may.csv",
        "status": "completed", "created_at": "…",
        "monitoring_end": "2026-05-31T00:00:00.000Z",
        "record_superseded_at": "2026-06-01T10:00:00.000Z" }
    ],
    "meta": { "total": 12, "truncated": true }
  }
}

Attach the latest metric per category for each row's location, batched across the page:

GET /ingestions/assets?include=metrics                  # all four categories
GET /ingestions/assets?include=metrics.deforestation    # one
GET /ingestions/assets?include=metrics.emissions,metrics.water_stress

The dotted values union, and bare metrics means all four — so mixing them yields all four. An unknown category is a 400 naming the allowed values.

Each element is the same metric resource the /metrics/... routes return. links.metrics_<category> points at that route for each requested category.

metrics.deforestation is not attributes.deforestation. The relationship is the measured deforestation metric for the location. The attribute is the EUDR compliance roll-up — plot counts and areas — from ?include=deforestation. Reading one and reporting the other is the mistake this note exists to prevent.

Add include=audit_trails to attach every EUDR audit trail (DDS record) covering a row's location, with each one's status:

"audit_trails": {
  "data": [
    { "id": "…", "name": "Coffee — BR",
      "lifecycle_status": "accepted",
      "reference_number": "25NLxxxxxxxxx",
      "created_at": "2026-05-01T00:00:00.000Z",
      "pinned_from_asset_task_id": "<the upload the filing pinned>",
      "pinned_record_is_live": false }
  ],
  "meta": { "total": 3, "truncated": false }
}

GET /regulations/eudr/audit-trail?filter[location_id]=eq:<location_id>

A row names every id needed to follow it, so grouping and drilling take no second request.

"attributes": {
  "location_id": "<this plot's location>",
  "location_type": "plot",
  "parent_shed_location_id": "<the shed's location>",
  "parent_facility_location_id": "<the facility's location>"
},
"links": {
  "parent_shed": "/locations/sheds/<the shed's location>",
  "parent_facility": "/locations/facilities/<the facility's location>"
}

Each row carries attributes.collection_ids — the supply-shed / plot collection hashes (bq_hash, the PMTiles / batch keys) for that row's resolved location:

• facility → its catchment shed hash(es)
• shed → the shed's own hash
• plot → the plot's collection hash

Under ?rollup=true a folded plot row lists the distinct hashes across the whole task. The field is omitted where the sco2 collection tables aren't available in the environment, and under ?rollup=unit, where it is not defined at the supplier-unit grain.

?rollup=task is the explicit spelling of ?rollup=true. The two return identical responses. For one row per supplier unit, see Rollup by supplier unit below.

A plot upload resolves to many asset rows (one per plot). Pass ?rollup=true to fold every plot task (location_type = 'plot') into a single row per task; facility/shed rows stay individual.

GET /ingestions/assets?rollup=true&include=deforestation

On a rolled row:

• id = the plot asset_task_id.
• asset_data is folded across the task's plots: each key is a scalar when identical on every plot, else an array of the distinct values. Arrays are capped; keys whose value set was truncated (or "*" when the per-task entity scan itself was capped) are listed under a reserved _truncated entry.
• deforestation (when included) is the asset_task (task-grain) summary — the task's roll-up — not a per-plot verdict. Facility/shed rows keep their per-location roll-up. Since EPO-2331 that roll-up counts only the plots a current record owns, so a plot whose record a later upload superseded is excluded. Note this row set is not deduplicated (that is GET /ingestions/assets/latest), so on this endpoint a superseded row's block can read zero while the row itself is still listed.
• normalised_data, assessments, and location_id / location_type are taken from the task's first (representative) plot (the earliest resolved plot). So the fold shows one plot's location detail + assessments while asset_data spans all plots. In geo formats the rolled row is a Feature with that representative plot's geometry (or null if none resolved yet).

{
  "type": "asset", "id": "<plot_task_id>",
  "attributes": {
    "location_id": "<first plot's staged_location id>",
    "location_type": "plot",
    "asset_data": {
      "country_code": "BR",                       // uniform → scalar
      "producer_name": ["Farm X", "Farm Y"],      // varies → distinct array
      "_truncated": ["some_high_cardinality_key"]
    },
    "deforestation": { "total_plots": 42, "compliant_plots": 40, ... }
  },
  "relationships": {
    "normalised_data": { /* first plot */ },
    "assessments": { /* first plot */ }
  }
}

Supported across offset and cursor pagination and all four response formats — JSON, application/geo+json, and the streaming application/x-ndjson / application/x-ndgeo+json variants (the collapse is done in SQL, so meta.total and page[cursor] operate on the folded row set; streaming pages that folded set under a cursor so memory stays bounded to one page). ?sort= and filter[...] are both honoured (EPO-1627). Filters apply at plot grain: a plot task appears when at least one of its plots matches, and the folded row summarises only the matching plots. Facility and shed rows filter directly.

?rollup=unit folds onto the supplier unit instead of the task: one row per (organization_id, asset_task_id, supplier unit). A plot task that holds three supplier units returns three rows, and each folds only its own plots. The same unit under two tasks stays two rows. Two organisations never share a row.

GET /ingestions/assets?rollup=unit&include=normalised_data,deforestation

The unit is asset_task_entity.supplier_unit, assigned by validation at ingest. A row with no unit falls back:

• A plot task with no units folds to one row, the same row ?rollup=true returns.
• A facility or shed record with no unit stays its own row, with its own asset id — the same row ?rollup=true returns. Records that share a unit fold into one row.

Every task ingested before 2026-09-16 carries no units, so it reads exactly as it does under ?rollup=true.

On a unit row:

• id is a deterministic uuid derived from (organisation, task, unit). It is stable across reads and works in page[cursor], but it is not a task id. Use attributes.asset_task_id to link to the task.
• relationships.normalised_data.attributes.supplier_unit carries the unit id. Request include=normalised_data.
• deforestation is the unit's own roll-up, from the per-unit summary (EPO-3088). A unit that is missing from a task that does have per-unit rows reports zeros. A task with no per-unit rows at all (not yet backfilled) uses its task-grain summary only when it has one unit; with several, the block and live_plot_count are absent, because no per-unit figure exists.
• live_plot_count is the unit's plot total, with or without include=deforestation. A folded unit row omits collection_ids and superseded_plot_count; an unfolded facility or shed record keeps its own collection_ids.
• asset_data, the representative plot, filters, sort, pagination and all four response formats behave as under ?rollup=true, at the unit grain.

Known limitation (EPO-3076). Two different suppliers can in rare cases receive the same unit id. Their plots then fold into one row.

Geometry lives inside the normalised_data relationship and is opt-in. To get it on the JSON response you need both include=normalised_data and include_geometries=true:

GET /ingestions/assets?include=normalised_data&include_geometries=true

Without the flag, normalised_data is returned without its geometry. Passing include_geometries=true without include=normalised_data is a no-op (the relationship that carries the geometry isn't expanded). A GeoJSON Accept format (application/geo+json) always includes geometry. See Query Parameters → Geometry.