Process Ingestion Assets

• Tag a subset of ingested assets by filtering on source data fields (e.g. tag all assets from a specific country).
• Trigger deforestation or emissions analysis on previously uploaded data.
• Re-process assets with different metrics or a different end date.

Use filter[field]=condition:value to select which assets to process. See Query Parameters for full syntax. A request with no narrowing filter must declare "scope": "organization" in the body, or it returns 400.

• filter[assets.task_id]=eq:<uuid> — scope to a specific ingestion task
• filter[normalised_data.location_type]=eq:facility — filter by location type
• filter[normalised_data.commodity_type]=eq:palm — filter by commodity
• filter[assessments.core.confidence_level]=eq:high — filter by core confidence level
• filter[assessments.core.confidence_score]=gte:0.8 — filter by minimum core confidence score
• filter[match_method]=eq:added — filter by match method
• filter[source_file]=eq:locations.csv — filter by original file name
• filter[assets.data.CITY]=eq:London — filter by source data fields using dot-notation
• filter[id]=in:<uuid1>,<uuid2> — filter specific entity IDs
• filter[eudr.product_type]=eq:timber — filter by EUDR product type

• Tags only (200 OK) — Tags are applied synchronously. The response is immediate.
• With metrics (202 Accepted) — Batch processing is triggered asynchronously. Use links.status to poll for progress via GET /ingestions/{id}.
• With assessments (200 OK) — ingestion-scope assessment rows are dispatched synchronously over the filtered set; the response returns once they're persisted. See Enabling assessments below.
• Filters — Use filter[...] query parameters to select which assets to process. Without a narrowing filter the run covers every asset the organization owns and bills for all of them, so it must be declared explicitly — see below.

At least one of metrics, tags, or a truthy assessments.include_* flag must be supplied — a body with none of these returns 400.

No filter? Add "scope": "organization" to the body to confirm an org-wide run — it bills for every asset the organization owns. Omitting both returns 400. Pairing a narrowing filter with scope: "organization" also returns 400, since the two contradict each other. filter[organization_id] is not narrowing — it selects the organization you already have, so it still needs the scope declaration and may be sent alongside it.

Set create_audit_trail: true to chain reprocess → deforestation → EUDR audit-trail record in a single request — the split-flow counterpart of the same opt-in on Ingest Assets (POST). Use it when you uploaded first, reviewed, and now kick off deforestation via this PUT: once the metrics run reaches a successful terminal (completed / completed_with_errors), the worker dispatches the same create task as POST /regulations/eudr/audit-trail, with no separate call.

Field	Type	Required	Description
create_audit_trail	boolean	No	When true, auto-create an EUDR audit-trail record once this metrics run finishes. Requires metrics to include deforestation (else 400).
create_audit_trail_pdf	boolean	No	Pre-render the audit-trail PDF at record creation. Defaults to true; set false to render on demand at first GET. Ignored unless create_audit_trail is true.
audit_trail_operator	object	No	Operator block stamped onto the record. Same shape as the operator block on POST /regulations/eudr/audit-trail. Only valid when create_audit_trail: true (else 400). Omitted → the org's default operator.
audit_trail_commodity	object	No	Commodity block stamped onto the record. hs_code may be omitted; it is never defaulted and a blank one blocks submission. Only valid when create_audit_trail: true (else 400). Omitted → a NULL commodity block (set later via PATCH).

Scope. The record covers exactly the task this PUT acts on:

• A filter[assets.task_id]=eq:<uuid> PUT reuses that task, so the record covers the whole task's plots.
• Any other filter creates a new task holding just the filtered subset, so the record covers precisely that subset.

Inherit-with-override (on a filter[assets.task_id] PUT). If the original upload already stamped audit-trail params, this PUT inherits them and overrides only the keys you pass — send create_audit_trail: true alone to reuse the upload's operator/commodity, or pass a block to override it.

Fires once. The dispatch is guarded (audit_trail_dispatched). If the upload already created the record, this PUT does not create a second or mutate the existing one — edit it via PATCH /regulations/eudr/audit-trail/:recordId. The opt-in only creates when no record exists yet.

Follow it. Poll links.status (GET /ingestions/{id}); once the task carries audit_trail_task_id, poll that audit-trail task for the created record id. A failed run creates nothing.

This endpoint accepts the same ingestion-scope assessments block as Ingest Assets (POST). The flags it honours are:

• include_core (default false) — add the core confidence/flags assessment to locations resolved by the filter.
• include_hazard (default false) — run natural-hazard risk scoring.
• include_infrastructure (default false) — run infrastructure nearest-feature enrichments (nearest_water_km / nearest_port_km / nearest_road_km plus port metadata, subject to the check_* toggles).

The runner is cache-aware: an existing assessment of the requested type for a location short-circuits to granting visibility (no assessment call).

PUT honours include_core post-upload — set { "assessments": { "include_core": true } } to add the core confidence/flags assessment to locations resolved by the filter. The runner is cache-aware: an existing core assessment for the location short-circuits to granting visibility (no assessment call).

The most common use of this endpoint is adding core, hazard, or infrastructure to locations that were uploaded without those assessments — for example, after a no-validation upload (the new opt-in default).

Unlike the POST /ingestions/assets endpoint, PUT does not re-run normalisation: locations resolved by the filter were already staged at upload time. PUT only dispatches the requested validation groups for those locations.

See docs/assessment-fields.md for the field-by-field reference, and Ingest Assets § Enabling assessments for the full table of include_* and check_* flags.

▶

Cache reuse across orgs

When the same location has already been assessed for another organisation, this endpoint reuses the existing assessment: no assessment call is made and your org is simply granted visibility. Cache misses fall through to a fresh assessment call and one new assessment per location.

The check_* access flags have a finer cache rule. They are recorded as sub_options on both the core and infrastructure assessments (see Ingest Assets § Access checks) — a cached assessment covers a request only if every truthy access flag in the request is also truthy on the cached assessment. A request that asks for an access check not previously run is a cache miss and refreshes the affected assessments so both old and new access flags are covered.

▶

Resolution rules

Identical to POST: each include_* flag is independent. Sub-options (check_water_access, check_port_proximity, check_road_access) are honoured against the matching group when one is requested in the same body. The runner does not auto-fall-back to anything — you must explicitly opt into at least one group (or a metric / tag), otherwise the request is treated as "no work" and rejected at the at-least-one-of validation.

▶

Disabling assessments

Omit the assessments block (or set every include_* to false) to dispatch no add-on work. Already-existing assessments are not touched — there is no "remove assessment" operation through this endpoint. To revoke visibility for a specific org, contact support tooling.

Required scope: ingestions:write