California Minimum General Transit Feed Specification (GTFS) Guidelines

Version 2.1 – Finalized March 25, 2022

Table of Contents

  • Purpose
  • Applicability
  • Overview
  • Principles
  • Data Process Checklist
  • Guideline Development Process
  • Tools and Resources
  • Frequently Asked Questions
  • Purpose

    The purpose of this document is to 1) establish baselines for the transit data that enable riders to understand when their next bus or train is arriving, how much their fare will be, and other important factors that impact each potential customer’s ability to easily access transit, and 2) explain the key standards that support this transit data. These baselines support the interoperability of the mobility data ecosystem for transit technology components. In aligning with the Mobility Data Interoperability Principles, these baselines can result in error-free operations of various transit technology systems and can deliver comprehensive, high-quality, analyzable data for decision-makers, researchers, and the general public.

    To achieve accurate and robust transit information sharing, California’s Department of Transportation (Caltrans) supports use of the globally recognized General Transit Feed Specification (GTFS) standard to describe trip-planning information, and, with these California Minimum GTFS Guidelines, establishes consistent expectations for the quality (accuracy, completeness, availability, and stability) of this data. Comprehensive, error-free GTFS is the foundation that enables critical transit service information sharing. With universal, standardized, high-quality trip-planning information, California’s transit riders, providers, and regulators can more effectively understand the transportation network—and riders can find transit on trip-planning maps and apps.

    Within the State of California, transit providers are expected by Caltrans to work toward compatibility with these Guidelines. These Guidelines describe the data that transit riders deserve to be able to access. Caltrans understands that many of the changes required to achieve these data improvements can take months to achieve (such as procuring new vendors). In limited cases, it may even take years to realize these changes (e.g., when new technologies and procedures are needed).

    Caltrans staff at the Division of Rail and Mass Transportation (DRMT) are available to assess a transit provider’s current GTFS data and co-develop a Transit Data Improvement Strategy. A Transit Data Improvement Strategy outlines the steps that both the transit provider and Caltrans will take over a two-year period to help the provider achieve compatibility. Learn about the Data Assessment process.


    These Guidelines pertain to public transit operations. GTFS effectively supports all modes of scheduled fixed-route public transit: rail, bus, ferries, streetcars, subways, cable cars, trolleybuses, gondolas, and more. Currently, GTFS best represents public transit operations with both fixed routes and fixed schedules, but demand-responsive transit services are expected to be added to GTFS through the upcoming GTFS-Flex extension.


    This Guidelines document has four sections:

    1. Principles: the goals that shaped the Guidelines

    2. Data Process Checklist: a list of outcomes for transit providers to meet that will ensure their GTFS data is of high quality

    3. Tools and resources: an explanation of Caltrans GTFS Helpdesk and other resources available to help California transit providers meet these Guidelines

    4. Frequently asked questions, including many standard GTFS terms


    These Guidelines were shaped by adopted transportation policy in California, as well as the desire to realize a transportation network that:

    • Provides the public with complete, correct, and up-to-date information (including standardized schedule, service, fare, access, and geographic data) to help riders of any ability plan journeys—as is nearly ubiquitous in the maps and apps on mobile phones

    • Provides riders with real-time vehicle arrival and departure information for making efficient decisions along their journey 

    • Makes information easy for any application developer to use by providing schedule and real-time GTFS data feeds that are both standardized and public 

    • Pursues industry standardization in order to provide better coordination, service delivery, and clear information for the transit industry—providers as well as their vendors—in the future

    Data Process Checklist

    In order to adhere to the above principles, transit providers (including rail, bus, and ferry) shall deliver the following outcomes:

    Schedule data

    Schedule data helps transit riders understand when service is scheduled to run, and how to understand a network of providers. To achieve consistency with the Guidelines, transit providers must:

    1. Publish valid GTFS Schedule (also known as GTFS Static) data.
    2. The GTFS Schedule data must be complete:
      • Representative of all fixed- and deviated-fixed route transit services under the transit providers’ purview;
      • Include data for all required and recommended files and fields in the base GTFS Schedule specification.
      • Follow all GTFS Schedule Best Practices (version 1.0 or later)
      • Include fares data using the Fares v2 format and applicable proposed files.
        This includes: fare_leg_rules, rider_categories, fare_containers, fare_products, and fare_capping.
      • Include tts_stop_name entries in stops.txt for stop names that are pronounced incorrectly in most mobile applications.
      • Include shapes.txt, with valid route shapes for each trip. Shapes should be precise enough to show the right-of-way that the vehicle uses and not inaccurately exit the right-of-way.
      • Include complete wheelchair_boarding data for both stops.txt and trips.txt
      • Include sufficient data instops.txt, pathways.txt, and levels.txt to navigate to, from, and between any boarding zone to street level with varying physical abilities including pathway_mode and num_stairs where applicable. This includes but is not limited to any stops that use parent_station in stops.txt as well as all significant or named transit facilities where an infrequent visitor may be concerned about accessibility.
    3. The GTFS Schedule dataset must be publicly accessible:
      • Published at a stable URL (permalink) from which it can be “fetched” automatically by trip-planning applications such as Google Maps, Apple Maps,
    4. The GTFS Schedule data should be accurate:
      •  Published GTFS Schedule datasets should accurately reflect scheduled service as measured by achieving a score of “passing” or “perfect” in all categories of the GTFS Grading Scheme v1.
    5. The GTFS Schedule must be up to date:
      • Publish changes to the base schedule at least one week in advance of every service change.

    Realtime data

    Realtime data gives riders up-to-date information about the location of transit vehicles (including rail, bus, and ferry). To achieve consistency with the Guidelines, transit providers must:

    1. Publish valid real-time updates using all three GTFS Realtime feeds: Trip Updates, Vehicle Positions, and Alerts.
      • Produce no critical errors in the Center for Urban Transportation Research (CUTR) GTFS Realtime Validator, as reported in the previous month at “Critical” errors are those that impede or challenge the ability of transit riders to confidently plan or execute their journey. See List of Critical Validation Errors.
      • Be consistent with the GTFS Realtime Best Practices: Trip Updates, Vehicle Positions, and Alerts
    2. GTFS Realtime feeds must be complete:
      • Publish information for at least 99% of the vehicles in service at all times.
      • Include all recommended fields in the GTFS Realtime specification and in the GTFS Realtime Best Practices.
    3. GTFS Realtime feeds must be up-to-date:
      • Publish updates to Trip Updates and Vehicle Positions feed at least once every 20 seconds, including updated timestamps and data for each trip and vehicle in service.
    4. GTFS Realtime feeds must be compatible with Transit Provider’s GTFS Schedule (static) dataset:
      •  Ensure 100% of trip_ids for planned trips are consistent between the GTFS Schedule and GTFS Realtime sources.
    5. The GTFS Realtime datasets must be publicly accessible:
      • Published at a stable URL (permalink) from which it can be “fetched” automatically by trip-planning applications.

    Access to data

    Transit providers must minimize any barriers to riders’ ability to access accurate trip-planning data regardless of their chosen platform. They must do so in the following ways:

    1. Publish a link to all GTFS Schedule and all GTFS Realtime datasets on their website. Transit providers can either publish the links to GTFS data directly on their websites or refer to a regional partner where the data can be found. These local and regional websites must be in agreement on the canonical version of each provider’s GTFS data.

    2. Publish all GTFS Schedule and GTFS Realtime datasets to global GTFS aggregators, including:

    3. Include an open license that allows commercial use. See Caltrans’ model language for examples, or read more about what makes a license open.

    4. If a provider chooses to require authentication to access GTFS Realtime feeds, it is reasonable and allowed to require users to register for a unique API key that can be used during the process of making HTTP requests for GTFS Realtime data. This can include allowing the API key to be accepted as a request parameter or request header.

      Other means of authentication that require extra effort are discouraged. These include requiring users to frequently renew their API keys, requiring requests be made from specific IP addresses, or using authenticated request protocols other than the HTTP protocol.

      Authentication registration must be:

      • Straightforward: Posting easily discoverable instructions to register for an API key on either the transit provider’s or a regional partner’s website.
      • Quick: Automating the registration process so that approval is not contingent on the applicant’s intended use.
      • Transparent: Specifying terms of use for the API key, including recommended access rates and the process for reinstating an account that has exceeded rate limits.

    Technical contacts

    To ensure that consumers of GTFS data can report any potential data quality issues, transit providers should:

    1. Identify a specific technical contact who knows how to triage inquiries about GTFS. This contact could be, for example, staff at the transit provider or a vendor. 

    2. Take care to reassure the public that the recommended contact is indeed an appropriate technical contact. This can be achieved in one of three ways:

      • Use a GTFS-specific email address, such as “” or “”
      • Designate an individual who is knowledgeable about GTFS, such as “”
      • On a transit provider’s website, it is possible to reassure the viewer that a general contact is appropriate for GTFS questions. For example: “Send your GTFS feedback to our customer support.” If this is explained on the website, the GTFS feed can refer to the same contact.
    3. Provide technical contacts in two locations:

      • Alongside the GTFS feeds on either their (or their regional partner’s) website.
      • Within the published GTFS Schedule dataset in the feed_contact_email field within the feed_info.txt file.


    Transit providers should make a plan to keep GTFS data accurate and complete into the future. Have a specific, time-bound plan in place to meet and remain consistent with these Guidelines. This may include co-developing a Transit Data Improvement Strategy with Caltrans’ Division of Rail and Mass Transportation (DRMT).

    Guideline development process

    These Guidelines were developed by the California Integrated Travel Project (Cal-ITP) team at Caltrans. Version 1.0 was published in September 2020, and Version 2.0 was published in September 2021. Version 2.1 is a clarification update only, with no change in implied meaning.

    This document will be updated once a year, at which time Caltrans will evaluate potential changes based on feedback, experience, and additional opportunities consistent with global data standards and/or technology. Please send Guidelines comments with suggested edits to Caltrans may update or simplify the wording of the Guidelines on a more frequent basis for clarity, which would result in a minor update to the version number (e.g., from 2.0 to 2.1). 

    Referenced Documents

    The outcomes above are derived from the following resources:

    Future GTFS extensions

    Caltrans anticipates adding the GTFS extensions listed in this section to the Guidelines once they are adopted in the official GTFS definition. Caltrans encourages transit providers to actively participate in the discussion and development of these proposals by:

    • Commenting on the draft documents themselves.

    • Participating in MobilityData member meetings (base membership is free for public agencies).

    • Discussing issues and proposed incremental changes to the specifications in the GTFS specification repository.

    • Emailing to express your priorities so that we can help you navigate the process, advocate on your behalf, and/or evaluate additional information-sharing mechanisms.


    GTFS-Fares 2.0 significantly expands the fare-related functionality of GTFS, including rush-hour fares, fare containers (such as physical cards and apps that can store purchased fares), and multiple-fare products (such as weekly and monthly passes). Caltrans is in close coordination with the data producers and consumers (such as journey-planning maps and apps, some of which are actively using it and displaying these fares to customers) that are advancing the adoption of this extension, and are confident enough in its progress to include it in this version of the GTFS Minimum Guidelines.  

    See also: How can I create Fares

    Anticipated Adoption: Summer 2022


    While the core components of GTFS-Pathways have been fully incorporated into GTFS, there are several outstanding items in the full GTFS-Pathways proposal that are on track to be adopted at a later date and that are critical to creating comprehensive accessibility to transit route planning and wayfinding:

    • Additional fields in pathways.txt, such as text-to-speech instructions, wheelchair assistance information, equipment-failure reporting, tactile strips, etc.

    • GTFS-PathwaysEvolutions, which indicates planned or scheduled entrance or exit closures, elevator outages, escalator outages, etc. 

    • GTFS-StationUpdate, the real-time Pathways component that encodes real-time information and alerts about outages to pathways such as elevators and escalators.

    See also: How do I create Pathways data?

    Anticipated Updates: 2022


    The GTFS-Text-To-Speech specification extension has been adopted for stop_name, and proposals for other fields are awaiting adoption. Those other fields include:

    • Agency name

    • Route name (short name and long name)

    • Trip name

    • Headsign (trip and stop)

    See also: Improving Accessibility of Transit Customer Information entry in the Transit Technology Playbook

    Anticipated adoption: 2022

    Shared identifiers

    When one transit provider overlaps with another—for example, when multiple transit agencies serve the same train or bus station, or when systems offer interagency fare discounts—it would be helpful for the providers to describe that relationship.

    MobilityData is developing an approach to create a reference for identifiers. These stable identifiers will serve as aliases and not replace any local transit provider identifiers (such as stop or route IDs). 

    Anticipated adoption: 2022 


    GTFS-Flex describes “flexible” or “demand-responsive” transit, meaning any transit service where riders do not get on or off at fixed stops along a fixed route, such as:

    • Dial-a-ride/paratransit services 

    • Transit services where a vehicle can deviate from a fixed route to pick up or drop off riders

    • Transit services where riders can board or alight anywhere within a zone

    Transit providers should begin including GTFS-Flex services as part of their GTFS feeds in order to support inclusion in trip-planning applications.

    See also: How can I create GTFS Flex data?

    Anticipated adoption: Spring 2022

    General On-Demand Feed Specification (GOFS)

    GTFS-OnDemand is an effort to expand the range of on-demand mobility services covered by GTFS and GTFS-Flex. The types of transportation intended to be covered by GTFS-On Demand 1.0 include:

    • Private taxi services

    • Private transportation network companies (TNCs), such as Uber and Lyft

    • Demand-responsive transit services that would otherwise be covered by GTFS-Flex

    GTFS-OnDemand 1.0 extends supported use cases envisioned as part of GTFS-Flex to add:

    • Realtime service updates

    • Accurate pricing information, including booking trips via deep-linking

    Anticipated adoption: 2022


    GTFS-Vehicles encodes transit vehicle characteristics, such as seating capacity, bike capacity, and various accessibility-related attributes. GTFS-Vehicles, when adopted, will be part of the Guidelines for transit providers with fleets that are not able to represent their accessibility via wheelchair or mobility device at the trip or stop level. In addition, the extension will allow transit providers to describe vehicle propulsion type (diesel, electric, etc.), which will enable statewide aggregation and reporting.

    Anticipated adoption: 2022

    Tools and Resources

    Caltrans maintains several resources to support transit providers in their efforts to meet these Guidelines.

    Data assessments

    How well does a transit provider meet the outcomes listed in the Data Process Checklist? Caltrans is available to formally assess this consistency on request by California transit providers. Caltrans staff are reviewing every California transit provider’s consistency with the checklist once a year and reaching out to each transit provider to share and discuss those findings. To proactively request an assessment, contact

    If transit providers would like support in resolving identified gaps, Caltrans provides technical assistance to create a Transit Data Improvement Strategy. A Transit Data Improvement Strategy:

    1. Has a two-year planning horizon with clear goals.

    2. Articulates how the transit provider will meet the California Minimum GTFS Guidelines, naming any specific hurdles.

    3. Defines which resources Caltrans will provide to help the provider overcome these specified hurdles.

    4. Will be updated in 2022 while Caltrans evaluates next steps.

    Products and services

    For California transit providers that do not currently have GTFS Schedule data, Caltrans offers technical assistance via a vendor to create and maintain this data on their behalf, at no cost to transit providers, through 2021.

    For California transit providers that do not currently have the hardware or software to create GTFS Realtime, Caltrans’ Cal-ITP offers GTFS Realtime as a Service (GRaaS), which, using ultra-low hardware costs and no software costs, produces GTFS Realtime data. The Cal-ITP team is available to support implementation at no cost to transit providers and can help support initial hardware acquisition. For more information, contact

    For other hardware and software that providers need in order to produce and maintain GTFS Schedule or GTFS Realtime, Cal-ITP invites providers to acquire these services through pre-negotiated, competitively bid contracts at, as they become available.


    Have a specific or exploratory question about transit data or strategy development? Caltrans’ team of technical experts is available at no cost to advise and support California transit providers. Contact to get started.

    Frequently Asked Questions

    What is GTFS?

    The General Transit Feed Specification (GTFS) is the global standard for describing transit schedules and operations for use by trip-planning applications. GTFS is used by thousands of agencies worldwide and is by far the most common data standard produced by U.S. transit agencies.

    First created in 2006 through a public-private partnership between TriMet—the public transit agency in Portland, Oregon—and Google, the continued development and refinement of the GTFS specification is carried out by a global community of public and private GTFS data producers and consumers. Officially recognized additions and modifications of the spec are reviewed according to the GTFS Extension Process and approval is facilitated by the independent nonprofit organization MobilityData.

    How do transit riders and the public "see" this GTFS data?

    The most common ways for transit riders to see the data is via:

    • A consumer-facing application such as Google maps, Apple maps, or (through a web browser or phone interface)

    • Transit provider signage

    • Commercial displays (for example at coffee shops, offices, sports and events venues, and apartment buildings) 

     California’s raw GTFS data can be seen:

    Why did Caltrans develop these Guidelines?

    Caltrans developed the California Minimum GTFS Guidelines to ensure that data for transit providers in California meets the needs of travelers, as well as those who plan, manage, and operate the transportation network, including fare payment and other services contracted by providers. The Guidelines provide a consistent minimum expectation to ensure that the transit network is understandable and accessible for people with all levels of ability.

    Does my organization need to follow the Guidelines?

    We recommend that transit providers follow these Guidelines in order to best serve the public by providing accurate, complete, and up-to-date transit information. Research shows that transit riders respond positively to high-quality transit information, both in terms of reducing perceived wait times and increasing ridership. See The Data Transit Riders Want, published by TransitCenter in 2018, for more information.

    Providers who maintain a Transit Data Improvement Strategy that maps their progress toward meeting the Guidelines can receive additional benefits from Caltrans. These providers are eligible for certain forms of discretionary funding and can participate in the statewide procurements published on the California Mobility Marketplace. Learn more about creating a Transit Data Improvement Strategy.

    Vendors with products and services that support consistency with the Guidelines are encouraged to participate in these Requests for Proposals.

    How do I know if my organization is compliant with these Guidelines?

    Encourage the department or vendor providing your organization’s technical services to review the Data Process Checklist. If you need assistance in assessment, please contact

    How can I comply with these Guidelines if I don't already? How can I get help implementing these?

    There are a number of potential pathways toward Guideline compliance, depending on the current data pipeline. This can include:

    • Identifying funding for equipment
    • Adding these Guidelines in future vendor contracts and procurements
    • Collecting and maintaining additional data
    • Updating website language

    See Tools and Resources for a list of specific offerings to help transit providers meet these Guidelines.

    How do I prioritize which Guidelines to focus on?

    The Guidelines describe the information that Transit Riders (and Providers) deserve and that is currently feasible within the GTFS specification. As such, we recommend setting this as the minimum bar for achievement. That said, Schedule Data Guideline #1 must be met in order to provide any information to riders and should be prioritized first:

    • Publish valid GTFS Schedule (also known as GTFS Static) data. 

    Once you are publishing valid GTFS Schedule data, Guideline #6 should be prioritized in order to provide riders with the up-to-date information they deserve, and to unlock benefits such as leveraging the California Mobility Marketplace:

    • Publish valid real-time updates using all three GTFS Realtime feeds: Trip Updates, Vehicle Positions, and Alerts.

    What is a “stable URL?”

    A stable (or “static”) URL (or “permalink”) is one that doesn’t change. This is especially important for GTFS Schedule data because it assures data consumers that they can reliably access the latest version of data. When new GTFS data is posted in a different location, it’s not obvious that the data from the old location is now invalid, which can result in transit riders being given out-of-date information, or none at all.

    The GTFS Dataset Publishing & General Practices provides guidance on the recommended practice of hosting GTFS data on a transit provider’s website. A consistent link to cloud storage or an FTP location would also satisfy these Guidelines. 

    When possible:

    • The stable URL should use the Transit Provider’s domain rather than a vendor’s, which may change over time. Example:

    • GTFS data representing future service or planned changes/augmentation to the GTFS data is reflected at another permalink to allow for back-and-forth troubleshooting ahead of time. Example:

    Providing a static URL for the most recent data does not prevent storage of historical GTFS data on websites at different addresses. For example:




    Uploading a GTFS file to the Google Transit Partner portal does not satisfy the static URL guideline, nor does hosting it on the transit provider website with a date or version in the file name or URL structure.

    Can a local or regional government impose guidelines that are stricter than these Guidelines?

    Yes. Caltrans welcomes the California transit community to provide more information than is specified in these minimum Guidelines, as long as these additional or stricter requirements don’t conflict with or dilute these Guidelines.

    How do I publish GTFS for both present and future service?

    There are generally two acceptable methods to meet the requirement of describing planned service changes at least one week in advance of them happening:

    1. Publish two services in a single feed using service_ids feature in the GTFS specification to distinguish them.

    2. Publish the “future” feed to a dedicated permalink; for example Los Angeles Metro publishes their “future-service” feed to a different Git “branch” enabling a permalink download at

    How do I publish my GTFS data to aggregators?

    OpenMobilityData and Transitland are the two largest and most stable feed repositories. Data consumers rely on these to find GTFS feeds for their applications, and being absent from these aggregators can preclude a transit provider from inclusion in maps and trip-planning applications. Transit providers and vendors can submit their feeds to these aggregators directly by following the instructions below.

    How do I publish my GTFS data to trip-planning applications?

    Once published, transit providers will want to get their GTFS data into popular trip-planning applications for the general public to discover and use. Each application has its own process, and key applications are listed below:

    How do I select an open data license?

    Agency GTFS data should be offered under the latest version of the Open Data Commons Attributions (ODC-BY) or Creative Commons Attributions license (currently CC-BY 3.0), which is consistent with the license required by the National Transit Map. These licenses should be adopted as-is, without additional requirements that would add undue complexity down the line.

    Other “attribution” licenses are often attractive and are also fine to use; however, “share-alike” type licenses limit the use of the data by some user applications and should be avoided. See Model Website Language for more information.

    What are the GTFS and GTFS Realtime Best Practices?

    The GTFS Best Practices and GTFS Realtime Best Practices are community-driven sets of requirements above and beyond the minimum GTFS specification to facilitate a more seamless customer experience. They are managed by MobilityData.

    What does it mean to have my data validated?

    Data validators can validate if the form and function of the dataset meet the data specification and fall within reasonable bounds (e.g. for the scheduled time for a transit trip to stop “12:01” is valid, but both “noon” and “11:62” would raise an error). However, validators cannot evaluate if the data is correct (e.g. if the bus is scheduled to stop at “12:01” but the GTFS Schedule instead has “12:17”). 

    There are currently three validator programs that may be used to validate GTFS data which Caltrans uses and are open-source and available for anyone to use (see note below):

    1. Canonical GTFS Schedule Validator, maintained by MobilityData. This is the same validator used by Google and a number of others. 

    2. GTFS Realtime Validator created by the Center for Urban Transportation Research (CUTR). This is the validator that Caltrans uses.

    3. GTFS Fares v2 Validator, created by the Transit App.

    All of these validators offer useful insights, but each require a high level of comfort running technical applications. While Caltrans is developing user-friendly interfaces to make these both easier to use, any California transit provider can email to request that Caltrans run these validators on their data and share the results.

    How can I create Fares v2 data?

    Over the past year, Caltrans has been working with Transit Providers to help them code and publish their fares. California transit providers who do not yet have their fares coded in Fares v2 format should aim to do so via:

    • Consulting instructions and resources in “Showing Customers Your Fares” entry in the Transit Technology Playbook,

    • Asking your GTFS vendor, or

    • Emailing to request additional assistance. 

    Many simple fare structures can be represented with minimal effort.

    Key resources:

    How can I create Pathways data?

    California transit providers who do not yet have stations and key pedestrian corridors coded in pathways format should aim to do so via:

    • Using tools and resources below to code it internally, 

    • Asking your GTFS vendor, or

    • Emailing to request additional assistance. 

    Key Resources:

    How can I create GTFS Flex data?

    Over the past year, Caltrans has been working with Transit Providers to help them code and publish demand-responsive transit using the draft GTFS Flex specification. California transit providers who do not yet have their demand-responsive coded in GTFS should aim to do so via:

    • Consulting instructions and resources in “Showing Customers Demand Responsive Transit” entry in the Transit Technology Playbook,

    • Asking your GTFS vendor, or

    • Emailing to request additional assistance. 

    Many simple demand responsive service patterns can be represented with minimal effort and can be published within or separate from your fixed-route transit GTFS dataset.

    Key resources:

    What does a Transit Data Assessment look like?

    To see how the Guidelines look in the context of a real transit provider, review this example of a recent assessment.

    Where can I get more support?

    Caltrans is here to help transit providers understand and successfully implement the Guidelines. Email to get started.