Demand-response service

On this page:

Introduction for agency staff

Public transit is complicated, especially when it doesn’t run in a straight line.
Dial-a-ride. On-demand transit. Paratransit. Guaranteed ride home. Safe ride. Last-mile taxi programs. Ridehail partnerships. Whether they’re door-to-door, stop-to-stop, or zone-to-zone… it can be a challenge for riders to use these options, or to even know that they exist.
Transit agencies want to make sure these services are available across all of their digital platforms. There’s the Transit app, obviously. 💅 But there’s also your website’s trip planner. In-system digital displays. And customer support tools.
These platforms already integrate fixed-route service, thanks to data standards like GTFS and GTFS-realtime. But often, demand-response service can feel like it’s on a remote island, far from other technologies.

Dial-a-ride and paratransit, for example, often rely on a telephone and an operator. And while some on-demand vendors might include fixed-route information within their proprietary app, that doesn’t help an agency’s customers access demand-response service using all of its apps, websites, or customer service tools.

Fortunately, there are open data standards that make it possible to get demand-response service information, plan trips, and even book rides across platforms. Vendors are increasingly adopting these data standards, and transit agencies play an important role in supporting a continued shift in this direction.

This guide helps transit agency staff know what to ask for so they can integrate demand-response services not just in Transit, but across all of an agency’s rider-facing platforms — no matter which vendors are involved.

What makes up an integration

There are three major components to integrate demand-response service into an agency’s rider-facing platforms:
  1. Service information: At its most basic level, a demand-response integration shares information about zones, service hours, and availability in a “machine-readable” format. This data can then be used by apps and other digital platforms to display the service to riders.
  2. Trip planning: Another common feature of integrations allows riders to plan trips from A to B using demand-response service, in combination with connecting modes. It can include a real-time ETA for pickup.
  3. Request, booking, and payment: Integrations can also enable riders to request, book, or pay for a trip from a rider-facing platform, using one of the following options. Implementation ranges from simple to complex:
    1. Simplest: Direct link to the demand-response provider’s app, website, or phone number
    2. App Clip (iOS) or Instant App (Android) offered by the demand-response provider
    3. Web-based integration built into the rider-facing platform
    4. Most complex: Native integration custom-built into the rider-facing platform

This integration with the Minnesota Department of Transportation includes zone and service information, trip planning, and web-based booking within the Transit app, all through open data standards.

Who's involved

In most cases, there are three parties involved in any demand-response integration:

🏢 Service owner 🚐 Demand-response provider 📲 Rider-facing platform
Typically a transit agency Vendor with demand-response technology or data production capability Digital interface that brings together all of an agency’s services
Procures service and negotiates contract with provider and rider-facing platform Produces data feed ➔ ➔ Consumes data feed

How they work together

There are two primary ways a demand-response provider and a rider-facing platform can deliver an integration for the service owner:

🤝 Cooperative 🏰 Walled garden
Different vendors work together to integrate demand-response service into one or more of an agency’s rider-facing platforms A demand-response provider integrates its own service into its own proprietary rider-facing platform, but not into the rest of an agency’s apps, websites, or customer information tools
Typically includes fees for work by both the provider and rider-facing platforms to set up and maintain the integration Offered by some vendors as a component of their demand-response offering

Data standards vs. Proprietary APIs

There are two general types of data feeds from demand-response providers:

🔄 Data standard 🔒 Proprietary API
Standardized format agreed upon by demand-response providers and rider-facing platforms, and encouraged by agencies Application Programming Interface that uses a non-standard format, unique to the demand-response provider that offers it
Once a provider or platform supports a data standard, it can more easily work with any partner that uses the same data standard Requires custom development work for each rider-facing platform to support each proprietary API. Once a platform supports a provider’s proprietary API, it can more easily add services from that specific provider.
Makes it simpler for agencies to work with different vendors Makes it more difficult for agencies to work with different vendors
Easier to validate quality and reliability of the data feed from each demand-response provider since they use a common benchmark Quality can vary greatly depending on what each demand-response provider includes in its API, how it is structured, and how it performs quality control
Examples: GTFS-flex, GOFS-lite Examples: RideCo API, Spare Labs API

Which data standard to ask for

The best way to get your demand-response service to appear in Transit, or in other platforms such as your agency’s website, is through open data standards. Which one you need depends largely on the type of demand-response service you offer:

💪 GTFS-flex 🪶 GOFS-lite
Primary services supported Paratransit, dial-a-ride, deviated fixed-route service On-demand transit, paratransit, taxi, ridehail
Zone or pickup type Zone-to-zone, point-to-zone, and other services can be hailed on the street or booked in advance Services that operate between or within zones and can be ordered in real-time
Primary purpose of data standard Service information and trip planning Service information and trip planning
Real-time pickup ETA Not available. Static service information only. Supported
Fare and pricing information Some support via GTFS files used for fixed-route services Supported directly in GOFS-lite
How booking or pickup requests are handled Direct link to the demand-response provider’s app, website, or phone number Direct link to the demand-response provider’s app, website, or phone number
Example in Transit MnDOT
 Pace On Demand
Supporting providers include Padam, Simpliciti, Trillium Transit (Optibus) DemandTrans, Pantonium
File format CSV JSON
Technical documentation GitHub
 Additional information and GitHub

Other data standards

  • Mobility Data Specification (MDS): It’s important to remember that MDS is not designed for rider-facing integrations. MDS does not include service information or enable trip planning, nor does it support booking and pickup requests. Instead, MDS gathers information about trips underway or already taken, to help regulators better understand how operators are using the public right-of-way.
  • GTFS-OnDemand (GOFS): This project brought the industry together to identify needs and develop a draft specification covering service information and trip planning for demand-response transit, but its complex format has not progressed to widespread use. As an offshoot of the GOFS project, Transit created GOFS-lite. This open data standard is available to the entire industry and contains information in common with GTFS-OnDemand, but in a more flexible, easier-to-use format.
  • Transport Operator Mobility-as-a-service Provider (TOMP) API: Developed by a Dutch working group, this API encompasses trip booking and transactions across multiple modes, including bikeshare, taxis, mopeds, fixed-route transit, and demand-response transit. It does not include service information and trip planning, but rather points to other data standards that serve these purposes. (GTFS-flex and GOFS-lite, for example, enable service information and trip planning for demand-response transit specifically.)
  • Transactional Data Specification (TDS): This data specification plays a similar role as TOMP, but specifically for demand-response service. It allows riders to book, request, and schedule trips in the same platform they use for service information and trip planning. Companies that can facilitate integrations using TDS include IBI Group and Cambridge Systematics. In collaboration with Cambridge Systematics and the Minnesota Department of Transportation, Transit has integrated a TDS-based booking integration, allowing riders to book and manage trips using a web-based interface directly within the app.

Proprietary APIs that work with Transit

In addition to the GTFS-flex and GOFS-lite standards, Transit works with a number of proprietary APIs that were independently developed by various demand-response providers.

These proprietary APIs function somewhat similarly to GOFS-lite:
  • All of them include service information
  • Most support trip planning and real-time ETAs
  • All include a direct link to the demand-response provider’s app for trip request, booking, and payment
The following demand-response providers have developed their own proprietary APIs that work in the Transit app: Curb, Lyft, Heetch, Ola, Padam, Revel, Riide, RideCo, Spare, Uber, and Via.
Transit has a preference for data standards. But since these proprietary APIs have already been integrated into the app, agencies can work with Transit to add demand-response services with these providers relatively easily. Moving forward, we encourage all demand-response providers to integrate using either the GTFS-flex or GOFS-lite data standards, depending on the type of service operated.

Common pitfalls

There are two major things to look out for when considering a demand-response integration:
⚠️  Data availability, formatting, and quality. Not all providers offer the same type of information, or the same quality of information, particularly if they are using a proprietary API:
  • Service information: Some providers do not offer service information, such as zone geography and service hours, through an API. It requires additional work by each rider-facing platform to manually code this information into a machine-readable format every time it changes, rather than being updated automatically through the API.
  • Real-time ETAs: Some providers are not able to provide estimated pickup times to riders before they request a trip, meaning that real-time ETAs are either inaccurate or not available to rider-facing platforms.
  • Trip planning: Some providers do not provide sufficient information in their API for rider-facing platforms to enable trip planning from A to B using demand-response service. Rather, they are only able to provide service information, such as zone geography and service hours.
Agencies can avoid these pitfalls by requiring in their contracting documents that both providers and rider-facing platforms demonstrate that they either:
  • Support GTFS-flex or GOFS-lite data feeds, or
  • Offer and can integrate a proprietary API that provides equivalent information as to what is required in a GTFS-flex or GOFS-lite feed
Which leads to the second common pitfall…
⚠️  Communication with both your provider and your rider platform about fees and timelines. Whether they use data standards or proprietary APIs, cooperative integrations require resources to set up and maintain from both the demand-response provider and the rider-facing platform. Make sure that you’re in touch with both parties about the timelines and costs involved if an integration is under consideration. In particular, determine in advance whether integration costs are to be borne by the agency or the demand-response provider.

RFP and contract examples

RFPs and contracts are where agencies have the most leverage to define the terms of an integration, and to reward potential vendors for using open data standards.

Some of these contract examples specify integrating with Transit by name. Of course agencies are free to specifically request an integration with the agreement of their rider-facing platform partners, whether that’s Transit or someone else. A growing number of agency RFPs also specify the use of GTFS-flex or GOFS-lite as part of these integrations.

Pace Suburban Bus  (Chicago suburbs, IL), January 2024: “Interoperability – Contractor shall make the application compatible with other Application Programming Interface (API) or general feed specifications (i.e, GOFS). General feed specifications should comply with MobilityData standards and use the latest revisions (including non‐finalized specifications, if necessary). At a minimum, deep linking will be required with Pace’s MaaS pilot.” (Page 7 of 15, Exhibit C of RFP)

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 Transit app 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 Transit app." (see page 1 of Statement of Work)

Still need help? Contact Us Contact Us