---
title: "Feature detail (lazy-loaded)"
method: GET
path: "/features/{id}/details"
tags: ["features"]
---

# Feature detail (lazy-loaded)

`GET /features/{id}/details`

Fetches detailed properties for a feature on demand. For parking-type
features (`truck_parking`, `truck_rest_areas`, `rest_areas`,
`service_plazas`, `parking`) the response also carries
`availability_trend[]` — the per-hour-of-day occupancy trend
(`{ hour, avg_available, avg_capacity, samples, low_samples }`, hours in
UTC) built from recorded live-occupancy history, so a client can answer
"is this lot typically full at my ETA?". Empty/omitted until the time
series has accumulated for that feature.

Some operators stop publishing a number once a lot is nearly full and
report only "at or below this site's low threshold" instead. Those
observations are counted in `low_samples` and are deliberately **excluded
from `avg_available`** — there is no real number behind them, and
substituting one (0, say) would assert the lot is *full*, a stronger
claim than the operator made. `avg_available` is therefore an average
over the counted samples only, and is omitted entirely for an hour whose
every observation withheld its count.

**Read the two together, and read them as counts of observations, not as
time.** Every bucket in this series is recorded *on change*, so a lot
that sits at its low threshold for three hours contributes one
`low_samples` while a lot whose count jitters contributes many. A
non-zero `low_samples` therefore tells you the lot **reaches** its low
threshold in that hour — not what fraction of the hour it spends there —
and an hour with a comfortable `avg_available` and a non-zero
`low_samples` is one you should not read as reliably roomy. `samples` is
the honest confidence signal for the bucket either way.

`low_samples` only accumulates for feeds that publish this state at all
(currently the MAASTO TPIMS states in North America), and only from when
that capture began — a bucket can read `low_samples: 0` because the lot
never withheld a count, or because the trailing window still reaches
back before the capture existed.

`cache` reports where the detail came from: `hit` (cached upstream
detail), `miss` (fetched upstream on this request), `poll` (the source
is enriched during polling, no on-demand fetch needed), `none` (no
detail loader exists for this source/resource), `error` (an upstream
fetch was attempted and failed) or `error-cached` (a recent failure is
still being served from the negative cache — no upstream call was made,
so retrying immediately will not help). Failures are remembered for a
short cooldown, and repeated source-wide failures pause on-demand
fetches for that source for a few minutes; both clear automatically.

## Path parameters

- `id` string, required

## Response `200`

Feature with full properties

## Other responses

- `404` — Feature not found

---

[API](https://skmtc.net/road511/apis/road511-traffic-api.md) · [All operations](https://skmtc.net/road511/apis/road511-traffic-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/road511/road511-traffic-api/versions/39a088b9c155/schema)