---
title: "Query truck restrictions along a corridor"
method: GET
path: "/truck/corridor"
tags: ["truck"]
---

# Query truck restrictions along a corridor

`GET /truck/corridor`

Returns all truck-related restrictions within a buffer around the straight-line path
between two points. Uses PostGIS spatial intersection (ST_Buffer + ST_Intersects).

Searches across feature types: `bridge_clearances`, `bridges`, `weight_restrictions`,
`truck_restrictions`, `truck_routes`, `freight_corridors`, `truck_parking`.

Results are ordered by distance from the corridor centerline. Each feature includes
`_distance_km` in its properties.

Only restrictions **in force now** are returned: a feature whose active window has
ended, or has not begun, is excluded. Seasonal limits (spring load restrictions)
carry their window on `start_time`/`end_time` and are otherwise live year-round.

**This endpoint does not filter by vehicle dimensions.** `height` and `weight` are
rejected with a 400 rather than accepted, because upstream feeds publish no
normalized clearance or weight for roughly 97% of the structures along a corridor.
Filtering on what little is normalized would drop everything we cannot judge, and a
short list reads as "this route is clear" — the one wrong answer that matters.

This endpoint gives you the **inventory** along the corridor; deciding what conflicts
with a specific vehicle is yours to do, or use `POST /routing/route`, which follows a
real route and emits a warning per restriction it can actually evaluate against the
truck profile.

Requires Pro+ plan with truck data access.

## Query parameters

- `from_lat` number, required
- `from_lng` number, required
- `to_lat` number, required
- `to_lng` number, required
- `buffer_km` number
- `jurisdiction` string
- `limit` integer

## Response `200`

Corridor restrictions with metadata

- object
  - `corridor` object
    - `buffer_km` number
    - `distance_km` number
    - `from` number[]
    - `to` number[]
  - `data` Feature[]
    - `description` string
    - `direction` string, nullable
    - `end_time` string, date-time, nullable
    - `estimated_end_time` string, date-time, nullable
    - `estimated_start_time` string, date-time, nullable
    - `feature_type` string
    - `geometry` object, nullable — Full GeoJSON geometry when the feature is a line or polygon; NULL for point-only features (read latitude/longitude instead).
    - `has_details` boolean — `true` when this feature's `(source, feature_type)` pair has a registered lazy-load detail function — calling `GET /features/{id}/details` or batching via `POST /features/details/batch` will return strictly richer data than what's in the list row (multi-view camera URLs, EV connector availability, sign message text, etc.). `false` means the list row already carries everything the source publishes, and the detail call would be a no-op. Not set on the `/features/geojson` path (that JSON is built in Postgres for performance — call `/features` for the hint).
    - `id` string
    - `is_active` boolean
    - `jurisdiction` string
    - `last_updated` string, date-time — When this feature's **content** last changed in our data — not when we last polled it. Re-observing an unchanged feature does not move it, so a camera or a truck restriction confirmed on every poll can legitimately carry a `last_updated` that is weeks old. Use it to answer "what changed since I last synced", and do not read it as a freshness or liveness signal. The comparison covers the fields we publish (name, description, is_active, the start/end/estimated_* times, `properties`, the geometry and the coordinates); it is value-level, so a re-worded description counts as a change. It is NOT the upstream's own timestamp. Where a source publishes one and we retain it, it appears inside `properties`. Changed 2026-07-23: this field used to be poll time, stamped on every refresh. It now matches `TrafficEvent.last_updated`, which has always meant content-change time — the two schemas previously disagreed on what the name meant, and now they do not.
    - `latitude` number
    - `longitude` number
    - `name` string
    - `properties` object — Type-specific fields (JSONB)
    - `road_name` string, nullable
    - `source` string
    - `source_id` string — Upstream-provided identifier, before our synthetic `id` prefix.
    - `start_time` string, date-time, nullable — Populated for time-bounded feature types (future_construction, alerts, special_events, truck_restrictions, etc.). NULL for permanent features.
  - `limit` integer
  - `total` integer

## Other responses

- `400` — Missing required coordinates
- `401` — API key required
- `403` — Plan does not include truck data access

---

[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/revisions/39a088b9c155/schema)