Demand-response service
On this page:
- Introduction for agency staff
- What makes up an integration
- Data standards vs. Proprietary APIs
- Common pitfalls
- RFP and contract examples
Introduction for agency staff
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.
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
- 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.
- 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.
- 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:
- Simplest: Direct link to the demand-response provider’s app, website, or phone number
- App Clip (iOS) or Instant App (Android) offered by the demand-response provider
- Web-based integration built into the rider-facing platform
- 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.
- 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
Common pitfalls
- 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.
- 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
RFP and contract examples
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.
RTA of Central Maryland, April 2024: "Software Requirements: Proven and demonstrable compatibility with the Transit app through General On-Demand Feed Specification (GOFS), GTFS-flex, or other proprietary API that offers similar information to third-party systems at RTA." (Page 26 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)