Work Zones on the Route: WZDX Lane Closures as an API

A route that’s clear when the load is dispatched can hit a lane closure 300 miles out. Work zones are the most dynamic disruption on a corridor — they appear, shift, narrow lanes, drop speed limits, and clear again on schedules that change week to week. A consumer nav app routes straight into one because it has no idea a crew is out there. For a fleet, that’s a missed appointment, a detour that blows the hours, or a truck threading a narrowed lane it shouldn’t be in. This is one of the most under-used pieces of road data in North American trucking — and there’s a federal standard that finally makes it tractable.

The Data Exists — in Two Dozen Places

The good news: work-zone data is no longer a scraping problem. The Federal Highway Administration’s Work Zone Data Exchange (WZDX) is a published specification for exactly this — a common way for state DOTs to broadcast active and planned work zones with lane-level detail. Two dozen states publish a WZDX feed today, and more come online each year.

The catch is the same one that shows up everywhere in this domain: a spec is not a single feed. Each state hosts its own WZDX endpoint, adopts the spec to a slightly different version, populates the optional fields to a different depth, and refreshes on its own cadence. A team that wants national work-zone coverage is back to writing and maintaining an integration per state — the exact tax we wrote about in the five road-data problems every NA fleet team knows. The data is standardized in shape and scattered in practice.

What a Work Zone Actually Needs to Tell You

A work zone is only useful to a planner when it answers operational questions, not just “there is construction here.” The fields that matter on the route:

• Where, precisely — the road segment geometry, not just a point, so it can be joined to a corridor.
• What’s restricted — lanes closed, shoulder work, width or height reductions, reduced speed limit.
• When — and this is the part most teams miss: work zones are time-bounded. A zone that’s planned for next Tuesday should plan differently than one that’s active right now. Start and end times — planned versus actual — are what separate “route around it today” from “warn the dispatcher it’s coming.”
• Are workers present — which changes both the legal speed and the risk profile.

That temporal dimension is why work zones belong with the rest of the time-bounded road data rather than in a static layer. The same way incidents move from active to archived on their own, a work zone carries its own schedule — so you can ask for what’s current on a corridor, or what’s coming before a planned departure, and get the right answer either way.

Putting It on the Corridor

The operational need isn’t “a database of work zones.” It’s “tell me the closures and speed reductions on this route, before the driver gets there.” Once every state’s WZDX feed is normalized into one schema, that becomes a single query against the corridor instead of a fan-out across two dozen endpoints:

GET /api/v1/features/corridor?
  type=work_zone&
  from=41.88,-87.63&
  to=39.10,-94.58&
  buffer_km=8&
  active_at=2026-06-26T14:00:00Z

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": { "type": "LineString", "coordinates": [ ... ] },
      "properties": {
        "type": "work_zone",
        "road_name": "I-55 SB",
        "lanes_closed": 1,
        "reduced_speed_mph": 45,
        "workers_present": true,
        "start_time": "2026-06-24T06:00:00Z",
        "end_time": "2026-06-29T20:00:00Z",
        "metadata": { "source_feed": "wzdx", "state": "IL" }
      }
    }
  ]
}

One call, the Chicago–Kansas City corridor, every active work zone on it with the lane and speed detail attached. Drop the active_at forward a few days and you’re planning around what will be there, not just what is. That’s the difference between data and a decision.

What You Can Build With It

With work zones in the same schema as everything else on the route, the integrations get short:

• Dispatch that warns before the closure — surface upcoming lane drops on a planned route so a load leaves with the detour already in it.
• ETA that respects the speed reduction — a 45-mph zone across 12 miles is real time a flat speed model misses.
• Driver alerts for workers-present zones — the safety and compliance angle, not just the routing one.
• Corridor risk views — work zones alongside bridge clearances and incidents in one layer (see truck routing with corridor hazard warnings).

Provenance, and the Honest Limits

Work-zone data comes from the official state DOT WZDX feeds, built on the FHWA standard — authoritative, public, and the differentiator over guessing from probe traffic. We don’t overstate it, though: coverage is only as wide as the states that publish, the field depth varies by state, and a feed is only as fresh as the DOT makes it. Where a state populates workers-present or exact lane counts, you get them; where it doesn’t, the feature says so rather than implying detail it doesn’t have. The job we take on is keeping two dozen of these feeds parsed, current, and in one shape as they each drift — so it’s not yours.

Try It

• API docs — the features and corridor surface, including work_zone
• Live map — see active work zones across the states that publish WZDX
• Free API key — no credit card, 14-day trial