# GTFS-Flex: dial-a-ride in the GTFS spec, and who actually publishes it

> GTFS-Flex has been part of the core specification since March 2024, and the validator polices it with 29 dedicated checks. We read every feed in the Mobility Database to see how many agencies actually use it.

Published 2026-08-21 by Nick Sawinyh.
Explainer in Feeds & Standards.
Canonical: https://its-feed.com/articles/what-is-gtfs-flex/
Keywords: gtfs flex, gtfs-flex, demand responsive transit, demand responsive transport, dial a ride data, on demand transit data, booking_rules.txt

---

GTFS-Flex is the part of [the General Transit Feed
Specification](https://gtfs.org/documentation/schedule/reference/) that describes
service a rider has to ask for. Dial-a-ride, route deviation, zone-based rural
service, senior and disability transportation: anything where the vehicle does
not simply show up at a posted time and place. It stopped being an extension in
March 2024, when the proposal was [merged into the main
specification](https://github.com/google/transit/pull/433) after years in draft.
The four files it adds now sit in the same reference document as `stops.txt` and
`trips.txt`.

We wanted to know how many agencies actually use it, so in August 2026 we read
every GTFS feed in the Mobility Database that is not marked deprecated. Of 892
readable US feeds, 333 carry at least one Flex file and 78 put anything in them.
Seventy-two of those 78 come from a single feed producer.

Flex covers service an operator runs and a rider requests. Vehicles a rider finds
and unlocks alone, scooters and bikeshare and the like, are described by a
separate set of specifications, [the shared-mobility data
stack](https://its-feed.com/articles/shared-mobility-data-stack/).

## The four files, and what each one is for

An [ordinary GTFS trip](https://its-feed.com/articles/what-is-gtfs/) is a sequence of `stop_times`
rows, each pointing at a stop and carrying an arrival time. Flex breaks both
halves of that. A Flex `stop_times` row can point at a zone or a group of stops
instead of a single stop, and it carries a window rather than a time.

| File | What it holds |
| --- | --- |
| `locations.geojson` | Pickup and drop-off zones drawn as GeoJSON polygons |
| `location_groups.txt` | Named groups of stops that a rider may be picked up at or dropped off at |
| `location_group_stops.txt` | Which stops belong to which group |
| `booking_rules.txt` | How far ahead a rider has to book, and how to do it |

Two `stop_times` fields carry the window, `start_pickup_drop_off_window` and
`end_pickup_drop_off_window`, and two more attach a booking rule to a stop time,
`pickup_booking_rule_id` and `drop_off_booking_rule_id`. All four files are
marked Optional, and both window fields are Conditionally Required, meaning they
become mandatory once a trip stops at a zone or a location group.

US publishers have settled firmly on one of the two options. Of the 78 US feeds
publishing Flex, 75 use GeoJSON zones, 1,666 polygons in total, and only six use
location groups. The handful we found outside the US lean the other way: seven of
the eight hang booking rules off ordinary stops and draw no polygons at all.
Eight feeds is too few to call it a regional convention, but it is a real
difference in how the same file set gets used, and a consumer that only handles
polygons will miss those services entirely.

None of this describes where the vehicle is right now. Flex is a statement of
what can be requested and when, which is the schedule side of GTFS. Live position
and delay travel separately, in [GTFS-Realtime](https://its-feed.com/articles/what-is-gtfs-realtime/).

## Counting who publishes it

Two cheap methods are available for answering this, and both get it badly wrong
in opposite directions.

The first is the Mobility Database's own `features` column, which flags which
feeds carry which optional parts of GTFS. It flags 36 sources as having Flex. Only 12 of those actually publish a Flex record, and 74
of the feeds that do publish one are not flagged at all. Most of the false positives carry the value `flex-v1`, which
refers to `continuous_pickup` and `continuous_drop_off`, an older and much
narrower idea that has nothing to do with the four files above.

The second method, opening the feeds and checking which ones contain the Flex
files, is worse. It gives 333 for the US. When we read those files rather than
just listing them, 255 turned out to hold a header row and nothing else.

![Horizontal bar chart of three nested counts of US GTFS feeds: 892 readable US GTFS feeds, 333 that carry a Flex file, and 78 that publish a Flex record. Annotations note that 255 of the 333 carry the files with a header row and no data, and that 72 of the 78 come from a single feed producer.](https://its-feed.com/charts/what-is-gtfs-flex-adoption.png)

*File presence is not adoption. Reading the files rather than listing them cuts the US count from 333 to 78. Source: ITS Feed analysis of the MobilityData GTFS catalog, probed 2026-08-21. 1,924 non-deprecated GTFS sources attempted, 1,632 readable, 292 unreachable. Method and exclusions in charts/scripts/what-is-gtfs-flex-adoption.py.*

The empty files are not agencies claiming service they do not run. They are a
template. Trillium Transit, which hosts 422 of the readable feeds in this
catalog, ships the Flex headers in every dataset it produces and fills them in
for the customers that have flexible service to describe. That
explains 248 of the 255 blanks, and it also explains the concentration on the
other side of the ledger: 72 of the 78 US feeds that publish real Flex records
are Trillium-hosted, and four more come from Cal-ITP, the California state
program.

By state, the 78 are more concentrated still. Colorado accounts for 40 of them
and Virginia for 15, so two states hold seventy percent of American GTFS-Flex
feeds. In Virginia's case the reason is documented: the Department of Rail and
Public Transportation [sponsored a pilot project to build Flex feeds for a
selection of agencies](https://drpt.virginia.gov/data/gtfs-feed-clearinghouse/)
along with a trip planner that could read them. Colorado's Flex feeds are all
served from a statewide Trillium download site. Adoption here looks less like a
market reaching a tipping point than like a short list of places where somebody
above the agency decided this was worth paying for.

Worldwide the same measurement gives 86 feeds. The eight outside the US are
Adelaide Metro, Switzerland's SKI+, Berlin-Brandenburg's VBB, Reus Transport in
Spain, and four French feeds including Ile-de-France Mobilites.

## What the booking rules say

`booking_rules.txt` is the file that makes Flex more than a map of shaded areas,
because it encodes the thing a rider actually needs to know. We read all 209
booking rules in the 78 US feeds.

![Horizontal bar chart of 209 US GTFS-Flex booking rules by how late a rider may book: no advance notice 22, same day 15 to 60 minutes ahead 12, same day 2 to 3 hours ahead 8, by the day before travel 144, 2 to 3 days before travel 18, a week before travel 4.](https://its-feed.com/charts/what-is-gtfs-flex-booking.png)

*Twenty-two rules out of 209 let a rider request a trip with no advance notice. The rest want a call, usually by five o'clock the previous afternoon. Source: ITS Feed analysis of booking_rules.txt in every US GTFS feed publishing Flex, probed 2026-08-21. Method in charts/scripts/what-is-gtfs-flex-booking.py.*

The shape is unambiguous. 144 of the 209 rules close booking the day before
travel, and the most common deadline is 5 p.m. Dolores
County in Colorado will take a request up to 30 days out and stops accepting at
5 p.m. the previous day. Broomfield's Easy Ride service closes three days before
travel at 10 a.m. Cape Cod Regional Transit Authority is unusual in publishing
all three booking types in one feed, with some services bookable in real time,
some needing two hours, and some closing at 5 p.m. the day before.

The field that says the most, though, is the one almost nobody fills in. Of the
209 rules, 187 carry a phone number and 16 carry a booking URL. At the feed
level, 74 of the 78 agencies give a number to call and nine give a link. Flex
exists so that demand-responsive service can appear in a trip planner, and the
overwhelming majority of what it currently describes ends with the instruction to
pick up the phone.

That is worth sitting with rather than treating as a failure. Rural dial-a-ride
is dispatched by people, often with eligibility rules that no booking form
captures, and a phone number is an honest description of how the service works.
It does mean that the promise of end-to-end trip planning across fixed route and
demand-responsive service, which is the reason the spec exists, is not what these
feeds are delivering yet.

## The validator polices Flex harder than anyone publishes it

The [canonical GTFS validator](https://gtfs-validator.mobilitydata.org/rules.html),
now at version 8, documents 178 active notices. Twenty-nine of them exist only to
check Flex constructs: unparsable polygons in `locations.geojson`, unsupported
GeoJSON geometry types, a `shape_dist_traveled` attached to a zone rather than a
stop, a prior-day booking rule missing its deadline, a pickup window on a stop
time whose pickup type says the trip is regularly scheduled.

That is one check in six aimed at a feature 8.7 percent of readable US feeds
use. An agency that publishes a malformed Flex feed will be told precisely what
is wrong with it. Whatever is holding Flex back sits somewhere else.

## Google will not take it

Google's participation requirements for transit partners are blunt about this.
The page states that ["Google Transit does not currently implement the GTFS-Flex
specification. GTFS-Flex datasets cannot be accepted at this
time."](https://support.google.com/transitpartners/answer/1111481)

Elsewhere the picture is better but narrower.
[OpenTripPlanner](https://docs.opentripplanner.org/en/latest/sandbox/Flex/)
implements the version merged in March 2024, though flex routing is a sandbox
feature that has to be switched on in `otp-config.json` rather than something a
deployment gets by default. Transit describes itself as the first major consumer
app to render Flex, [working with Minnesota DOT and fifteen rural
agencies](https://blog.transitapp.com/mndot-gtfs-flex-bringing-rural-riders-into-the-fold/)
to put pickup zones, service hours, and a call button in front of riders.

So an agency that does the work of publishing Flex gets picked up by Transit and
by whichever OpenTripPlanner deployments have the flag turned on, and stays
invisible in the app most of its riders already have on their phone. Whether that
trade justifies a procurement is a fair question for a rural agency with one
data person to ask, and it is the most plausible reason the count sits where it does.

## How much service is missing

The [National Transit Database's](https://its-feed.com/articles/national-transit-database/) monthly
ridership file covers 523 agencies reporting active service in the year to June 2026, almost all
of them full reporters. Of those, [410 operate demand-response or
demand-response-taxi
service](https://data.transportation.gov/Public-Transit/Complete-Monthly-Ridership-with-Adjustments-and-Es/8bui-9xvu).
Four in five agencies in the monthly panel run something a rider has to book.
The monthly panel is also only part of the industry: the 2024 annual database
counts 524 full reporters alongside 603 reduced reporters and 1,111 rural
reporters, and the reduced and rural ones do not appear in the 523 at all.

Set 410 against 78 and the size of the gap is clear enough. This is also
what [N-CATT's Flex guidebook](https://n-catt.org/guidebooks/updated-gtfs-flex/)
was pointing at in 2023 when it noted that the services missing from trip
planners are disproportionately the ones used by people with disabilities,
seniors, and rural riders. The guidebook put the number of agencies with Flex
data produced for them at "well over a hundred." Our count is of feeds published
and registered, which is a narrower thing, and the difference between the two is
probably the most useful number nobody has: data that exists somewhere but never
reaches a public feed does not put a bus on anyone's map.

## What to watch

The single event that would change the arithmetic is Google reversing its
position, and there is no sign of it. Its own reference page on where Google
Transit differs from GTFS carries a December 2022 cutoff, fifteen months before
Flex was voted in, and has not been revisited.

Short of that, watch the state programs. Colorado and Virginia produced 55 of the
78 feeds between them, which suggests that Flex adoption is driven by whoever is
paying for the feed rather than by individual agency decisions. California's
[transit data
guidelines](https://dot.ca.gov/cal-itp/california-transit-data-guidelines-faqs-v4_0)
currently say providers "should aim to" code demand-responsive service, with no
deadline attached. A state that made it a condition of funding would move the
national number more than any amount of tooling.

And watch `booking_url`. Nine feeds out of 78 currently publish a link a rider
can act on. Until that field fills in, GTFS-Flex is doing the first half of its
job, telling a rider that a service exists and roughly where it goes, then
handing the second half to a phone call and a weekday afternoon deadline.

For an agency weighing whether to bother, the honest summary is that the format
is finished, the validator is thorough, the largest consumer is closed, and the
places where Flex has actually shipped are the places where a state paid for it.
Nothing on that list is a data problem.

## Frequently asked questions

### What is GTFS-Flex?

GTFS-Flex is the part of the General Transit Feed Specification that describes service a rider has to request rather than simply catch: dial-a-ride, deviated fixed routes, and zone-based rural service. It adds four files to a GTFS dataset. locations.geojson draws pickup and drop-off zones as polygons, location_groups.txt and location_group_stops.txt name groups of existing stops that serve the same purpose, and booking_rules.txt records how far in advance a rider has to book and how. It was merged into the main GTFS specification in March 2024, so it is no longer an extension.

### Is GTFS-Flex still an extension?

No. The Flex proposal was merged into the core GTFS Schedule specification in March 2024. The four Flex files and the associated stop_times fields now sit in the same reference document as stops.txt and trips.txt, all marked Optional. The separate MobilityData GTFS-Flex repository was deprecated after the merge.

### Does Google Maps support GTFS-Flex?

No. Google's own participation requirements for transit partners state that Google Transit does not currently implement the GTFS-Flex specification and that GTFS-Flex datasets cannot be accepted at this time. Transit and trip planners built on OpenTripPlanner do consume Flex, so an agency that publishes it will be visible in some apps and invisible in the largest one.

### How many agencies publish GTFS-Flex?

In our August 2026 read of every non-deprecated GTFS feed in the Mobility Database, 78 readable US feeds published at least one Flex record, out of 892 readable US feeds. Another 255 US feeds carried the Flex files with a header row and nothing in them, which is why a count based on file presence alone comes out more than four times too high.

### What does booking_rules.txt actually contain?

It records the terms under which a rider can request a trip: a booking_type of real time, same day with advance notice, or prior day; the minimum notice in minutes for same-day service; the earliest and latest day a request may be made for prior-day service; and free-text message, phone_number, info_url and booking_url fields. Across the 209 booking rules in US Flex feeds, 187 carry a phone number and 16 carry a booking URL.

### What is the difference between GTFS-Flex and microtransit?

Microtransit is a service model, usually app-booked shared rides in a defined zone. GTFS-Flex is a data format for describing any service a rider has to request, which includes microtransit but also traditional dial-a-ride, senior and ADA paratransit, and route deviation. A microtransit operator can publish GTFS-Flex, and most of the US agencies that do publish it are running conventional rural dial-a-ride rather than anything app-based.

---

Source: ITS Feed, https://its-feed.com/articles/what-is-gtfs-flex/
ITS Feed is an independent editorial site on the data and technology layer of transportation, published by the team at Veodyn. Figures trace to the sources linked inline.
Site index for agents: https://its-feed.com/llms.txt