Demand-Response and On-Demand Transit

On this page:


Demand-response transit can take many forms. For some transit agencies, especially in rural areas, dial-a-ride and demand-response service are well-established options that are only now beginning to enter the digital era. Meanwhile, a growing number of agencies have turned to microtransit, also known as on-demand transit. And agencies of virtually all sizes are looking to improve how they deliver paratransit service.

These door-to-door, point-to-point, or zone-to-zone services can struggle with low ridership and high operating costs — problems that are only exacerbated by the barriers potential riders must overcome to access these options. Demand-response services are often available only in limited zones or at certain times of day, and riders must call or download a new app to access the service, making it difficult for those who are not already regular riders to discover, understand, plan, and book their trip. At the time, transit agencies simply didn't have the expectation that anything other than fixed-route service would be available through apps like Google Maps or Transit.

With the explosion of interest in demand-response transit due to the pandemic, those expectations began to change. Transit has been working with over 40 transit agencies and 7 microtransit partners to make demand-response transit available alongside fixed-route service in our app. These integrations are helping riders see all of their transit options, while helping agencies of all sizes clearly communicate with riders about offerings beyond traditional fixed-route lines.

Initially, these integrations built using proprietary APIs from each service provider, to unique specifications agreed upon with each transit agency because unlike fixed-route transit or bikeshare, demand-response services did not have a GTFS-like data standard to provide basic information to riders. Implementation typically required access to private APIs, which created hurdles for all parties.

Recently, the advancement of open data standards has helped smooth the road ahead, allowing on-demand transit integrations to proliferate and reduce the time required for deployment in Transit. For agencies, the way forward will depend on the type of service they operate, which will determine what type of data standard they should pursue with their technology partners.

GTFS-flex, GOFS-lite and GOFS

  • GTFS-flex is used primarily for dial-a-ride, curb-to-curb, and deviated fixed-route services. Transit supports GTFS-flex. Example: dial-a-ride and other services from rural transit agencies across Minnesota are now shown in Transit thanks to an effort led by MnDOT.
  • GOFS-lite is a flexible format that is used for on-demand transit such as microtransit. 
  • GTFS-on demand (aka GOFS) is a comprehensive effort to define all flexible services, including taxi/ridehail. A working group led by MobilityData is continuing work on developing GOFS.

MobilityData, the not-for-profit managing mobility data standards like GTFS, has launched a working group of government agencies, not-for-profits, microtransit providers, and apps — including Transit— to create an open data standard for an umbrella of ridehail, on-demand, and flexible services. It's called GTFS-OnDemand, or GOFS. As an offshoot of that project, Transit has developed GOFS-lite: a lightweight, flexible standard that is interoperable with GTFS-OnDemand and is simpler for Transit to integrate. If a microtransit provider can provide a GOFS-lite feed, their service offering can be made available in the app. You can find complete technical documentation for GOFS-lite on GitHub,

With an open data standard in place for on-demand providers to share real-time information about their services, agencies will be able to require GOFS-lite to facilitate these kinds of integrations as a baseline expectation when launching microtransit programs. That would allow apps like Transit to display service information to users, such as zones, ETAs, pricing, and even the ability to make a pick-up request. Most importantly, GOFS-lite makes it easy to combine on-demand transit with other services like fixed-route transit, or even bikeshare and scooters. That, in turn, helps ensure that every public dollar invested in microtransit promotes robust ridership and helps riders connect available services together for multimodal trips.

The possibilities for GOFS writ large go far beyond microtransit and, in the not-too-distant future, can extend to other demand-responsive services, such as paratransit. Transit is already contributing to efforts led by the California Association for Coordinated Transportation and US DOT’s ITS Joint Program Office to ensure that the benefits of digital on-demand standards extend to all communities, including users of paratransit, older adults, rural residents, and other traditionally underserved populations.

Guidance for public agencies

  • Ask potential microtransit vendors to provide GOFS-lite feeds. If they cannot provide GOFS-lite but can only offer a private API, share that API for evaluation by apps that have integrated similar services in the past. We’re not the only company in this category, but you can use our requirements to get you started. 
  • If your agency is putting out a Request for Proposals, score providers on their proven ability to work with third parties, not just their willingness to do it.
  • Agencies, cities, apps, and on-demand providers alike can get involved in conversations around GOFS, and become an early adopter of GOFS-lite to promote this new open data standard. 

RFP and contract examples

This page will be regularly updated with new RFP and contract examples, especially as GOFS-lite continues to gain momentum. 

Given that the idea of integrating an on-demand service into trip planning apps like Transit is relatively new, some of the contract examples here specify integrating with Transit by name. While of course we’re happy to be referenced directly, and it’s not a bad idea to specifically request an integration with your app provider (whether Transit or someone else), other approaches are possible. For instance, agencies should consider encouraging microtransit operators to provide GOFS-lite feeds. 

Because integration is still a complex task requiring development work from multiple parties, contracting agencies should make allowances for operators to subcontract with integrators and/or consider commissioning a separate contract for integration of microtransit services.

KCATA (Kansas City. MO-KS), September 2022: "The service must provide users with an estimated pickup time, time of arrival, and fare prior to confirmation of the ride. These service features must be available across all access methods. Services will ideally allow an interface with RideKC Apps to all full trip planning and connections from the flex to fixed routes."

RGRTA (Rochester, NY), January 2022: "To streamline the customer experience, RGRTA would like to offer a singular platform of payment for the customer to execute all rides across its network. The Masabi Just Ride platform offers an SDK (Software Development Kit) which will enable the functionality of payment integration... delivery of this information to the customer is via Transit App... The proposing vendor shall integrate and provide fare payment through this interface. RGRTA has the understanding that several firms that could respond to this RFP have integrated with parties on other projects and this requirement will not reduce competition. Vendors who meet this requirement will be scored more favorably than those that do not in the evaluation process. If any software development is necessary for the interface, Vendor shall provide in pricing sheet. If any additional hardware is necessary for interface Vendor shall provide in pricing sheet. Timeline to integrate with Masabi JustRide Platform and Transit App shall be incorporated into the overall project plan."

Saskatoon Transit (Saskatchewan), October 2021: "Move Saskatoon Transit closer toward a Mobility-as-a-Service (MaaS), integrating On Demand trip planning with existing trip planning tools for fixed routes (I.e: Transit app; Google Transit, other) so the customer experience is as seamless as possible. This solution will provide the customer with the available transportation choices based on their preferences and will suggest fixed route options in addition to On Demand."

St. Albert Transit (Alberta), May 2021: Included “Proven and demonstrable compatibility with the TransitApp through API or General On-Demand Feed Specification (GOFS)” as a desired attribute for microtransit vendors. (see bottom of page 21 of RFP)

VIA Metropolitan Transit (San Antonio, TX), February 2021: “VIA is also rolling out a new mobility payment platform in 2021 with Masabi and Transit app and is seeking a tightly integrated payment experience in selected partner’s Mobility on Demand app, utilizing the Masabi fare payment engine. Additionally, since Transit app will be utilizing the same Masabi fare payment engine, the Contractor shall work with Transit app to allow trip planning across fixed and Mobility on Demand routes right within Transit app. The whole trip could be planned, booked, and paid right within Transit app.” (see page 19 of RFP) and "VIA seeks to have provider directly integrate MOD trip planning within Transit app, where VIA customers can trip plan MOD journeys, bus travel, or combined bus and MOD journeys. Ideally, provider would allow full booking of the trip on the Transit app platform as well, but if not, the provider shall work with Transit app to link to the provider’s MOD app for booking." (see page 25 of RFP)

Durham Region Transit (Ontario), June 2020: Asks for "Seamless integration with TransitApp." (see page 1 of Statement of Work)

Still need help? Contact Us Contact Us