How Transit Integrates GTFS

Transit's data team often gets questions from transit agencies about how the app integrates GTFS, so we've developed this guidance to explain how to publish GTFS so it can easily be picked up by the app, and how to adjust your feed's metadata so schedules properly display not just in Transit, but in also in other apps.

Need to contact Transit's data team?

Have a technical question about your GTFS that's not answered here? Email and we can sort it out with you.


There are two simple rules for reliably publishing your agency's GTFS feed and ensuring that it gets integrated into the app:

  1. Datasets should be published at a public, permanent, static URL so the app can pick it up automatically. If an agency updates the dataset at its permanent URL, Transit will automatically recognize within 24 hours that the dataset has changed and will process the new data to update the app. Using a permanent URL removes the need for agencies to send out emails to their data consumers every time a new update is published.
  2. Agencies should publish GTFS at least one week before new service in that dataset is set to begin. When a new GTFS is posted, Transit merges old and new calendars internally, regardless of how far in the future the new GTFS begins, to ensure a seamless transition when there is a change to the GTFS. We urge agencies to publish future GTFS early, in the event that a new GTFS fails one of Transit's quality checks and requires human intervention from either Transit's team or the agency's team. This removes the possibility that active services disappear in the app after the previous calendars expire.

Improving your feed's metadata

Our team of transit analysts always reviews the GTFS files and makes internal adjustments. Transit's goal is to make the app experience best resemble the local rider experience. We typically adjust route colours and adjust metadata fields such as route_long_name, trip_headsign, stop_headsign and stop_name.

To help data publishers improve the metadata in their GTFS, we've developed this resource to show how various fields are displayed in the app. Following these guidelines will improve not just how the feed appears in Transit, but also in other apps as well.

Want more GTFS tips?

Take a look at GTFS Best Practices, developed by MobilityData in consultation with public transportation providers, developers of GTFS-consuming applications, consultants and academic organizations to define common practices and expectations for GTFS data.

Click on one of the following common dataset files to get started.

  • routes.txt
    • route_short_name & route_long_name
    • route_type
    • route_color & route_text_color
  • trips.txt
    • Unidirectional vs. bidirectional
    • When to use stop_headsign
    • trip_headsign
    • branch codes
    • trip_short_name
    • direction_id
    • wheelchair_accessible
  • stops.txt
    • wheelchair_boarding
    • stop_name
    • stop_code
  • stop_times.txt
    • arrival_time and departure_time
    • stop_headsign

Still need help? Contact Us Contact Us