The locations endpoints carry the same aggregate under the opt-in assessment include — note the singular assessment here (the ingestion surface uses the plural assessments; they address the same rows):

# Every location in a list
curl '/locations?include=assessment' -H 'x-api-key: ...'
# A single location (also works on the typed convenience routes)
curl '/locations/plots/{id}?include=assessment' -H 'x-api-key: ...'
curl '/locations/{id}?include=assessment'        -H 'x-api-key: ...'

The include is valid on the list routes (GET /locations, /locations/facilities, /locations/sheds, /locations/plots, /locations/commodity/{commodity}) and the single route (GET /locations/{id}). Each location gains a relationships.assessment object with the identical partition shape documented below.

The base list/single response is gated on locations:read; the three EUDR-scope partitions (art9, art10, eudr_profile) are additionally gated on assessments:read, exactly as on the ingestion surface — see EUDR-scope gate. Without include=assessment the response is unchanged (the relationship is omitted entirely). For deeper per-partition queries — filtering by risk level, paginating one row per applicable law, or refreshing — use the dedicated /assessments/{location_type}/{slug} endpoints.

relationships.assessments.attributes carries one slot per partition. Every slot is nullable — a slot is null when the partition was never produced for that location, when your organisation can't see it, or (for the EUDR-scope partitions) when your key lacks the scope to read it (see EUDR-scope gate).

{
  "data": [
    {
      "type": "asset",
      "id": "…",
      "attributes": { "location_type": "plot", "status": "completed", … },
      "relationships": {
        "assessments": {
          "type": "assessments",
          "attributes": {
            "core":                 { "confidence_score": 0.91, "confidence_level": "high", "flags": { … }, "sco2_run_at": "2026-01-12T08:04:11Z" },
            "hazard":               { "flags": { "natural_hazard_risk_level": "low", "flood_zone_pct": 4.2, … }, "sub_options": null, "sco2_run_at": "…" },
            "infrastructure":       { "distances": { … }, "shed": { … }, "climate": { … }, "sub_options": { … }, "sco2_run_at": "…" },
            "deforestation_screen": { "flags": { "deforestation": { … }, "deforestation_check_failed": false }, "sub_options": null, "sco2_run_at": "…" },
            "art9":                 { "flags": { "legality_risk_level": "low", … }, "sub_options": null, "sco2_run_at": "…" },
            "art10":                { "flags": { "article10_risk_level": "low", … }, "sub_options": null, "sco2_run_at": "…" },
            "eudr_profile":         { "flags": { "eudr_country_risk_tier": "standard", … }, "sub_options": null, "sco2_run_at": "…" },
            "legality_risk_level":  "low",
            "article10_risk_level": "low",
            "failure_reason":       null
          }
        }
      }
    }
  ],
  "meta": { "asset_task_id": "…", "overall_status": "completed", … },
  "links": { "self": "…" }
}

The base response is gated on ingestions:read (or locations:read on the locations surface). The three EUDR-scope partitions — art9 (legality), art10 (country-risk), and eudr_profile — are additionally gated on assessments:read:

• A key with assessments:read (or an unrestricted key) sees these slots populated when the data exists.
• A key without assessments:read always sees them as null — indistinguishable from "no such row." We don't reveal that gated data exists.

The two promoted scalars — legality_risk_level and article10_risk_level — stay ungated: they're always surfaced under the base scope so a list or table row carries the headline EUDR risk levels without a second fetch. The full detail (sources, applicable laws, scoring breakdown) stays on the gated art9 / art10 slots and the dedicated /assessments/{location_type}/legality and /country-risk slugs.

How the EUDR-scope partitions get populated varies: art9 / art10 only by a DDS create (POST /regulations/eudr/audit-trail); eudr_profile either by opting into include_eudr_profile on a plain ingestion (POST / PUT /ingestions/assets) or force-run at DDS creation. An ingestion that enables only include_hazard / include_infrastructure / include_core (i.e. without include_eudr_profile) leaves all three null regardless of scope. See assessments-overview.md for how each partition is produced.

The field-by-field reference for the ingestion-scope partitions lives in assessment-fields.md — the keys are identical here, nested under each slot's flags (or, for core, split between the promoted top-level fields and flags):

• core → Core group
• hazard → Hazard group
• art9 (legality) → Article 9 group
• art10 (country-risk) → Article 10 group

The two partitions split out after that page was written — eudr_profile and deforestation_screen — are documented here.

Presence and access flags (water_access, port_proximity, road_access, poi_presence, high_density on core.flags, and deforestation_check_failed on deforestation_screen.flags) are real JSON true / false, not the 0 / 1 integers sco2api emits upstream — fm-api coerces them at ingestion. Tri-state gradients (commodity_presence, building_presence) stay numeric (0 | 0.5 | 1) on purpose.

core.flags.commodity_invalid is true on a row whose commodity cell names no supported commodity, and absent otherwise. See The commodity column.

Without include=assessments the response is unchanged: assets carry no assessments relationship. The include is purely additive and opt-in; existing integrations that don't request it see the same payload as before.