This guide explains how to integrate with Google to provide users a seamless transport search experience on various Google surfaces, including Google Maps and Google Search. At a high level, the main integration specifications include:
- Two options for providing static data:
- GTFS-based integration: Providing a GTFS feed with ticketing extensions, for cases where you are the provider of the schedule data. We have some additional requirements for the GTFS-based integration.
- Stop-only integration: Providing just a list of stops, for cases where Google already has the schedule data from another source.
- A Partner API specification for providing dynamic data:
- Partner configuration: Providing partner information such as branding and contact details.
- Partner server: Implementing servers that support the Partner Server APIs.
Steps for integrating with Travel Transport
The following is an overview of the steps needed in order to build and test an end-to-end system for supporting Google's transport features. There are three main steps to the integration:
- Reviewing the participation requirements.
- Providing a feed of static data to Google.
- Supporting the Travel Transport API to enable dynamic queries of
fast-changing data like prices and availability. The API utilizes
identifiers provided by the static data feed from step 1, for example the
ticketing_stop_id
to identify stops.
1. Participation Requirements
Google's transport features unit displays itineraries and booking options with prices. To display your offer in the list, a good quality link and a matching final price are expected. For more details, review our participation requirements.
2. Providing a feed of static data
There are two options for providing static data, each applicable in specific circumstances. The main criterion to decide which option to use is whether you are the provider of the schedule data for the transit connections you want to offer booking functionality for. The easiest way to check if Google already has schedule data is to try to find connections for a particular operator on Google Maps.
Feature | GTFS-based integration | Stop-only integration |
---|---|---|
Use case | You already provide the GTFS with schedules and ticketing information. | Google already has the schedule data for the operator from another source. |
Required data | The GTFS ids. | A list of your stop IDs, with their geo coordinates. |
Effort | Low | Medium |
Option 1 applies if you are the provider of the GTFS feed for an operator. In this case, you also need to have setup a GTFS feed to supply the schedule information for Google first. Then follow the instructions in the GTFS-based integration section.
Option 2 applies if Google already receives schedule data for the operator from a different source. In this case, we don't need the full schedule information, but we still need a list of your stop IDs that we can use in the Travel Transport API (see below). To provide the list of stops follow the instructions in the Stop-only Integration section.
3. Supporting the Travel Transport API
To be listed as a booking partner with prices in the Transport Unit, Google needs to be able to fetch the latest pricing & availability information from partners. To enable this, partners are required to provide a service which implements the Partner Server APIs.
3.1. Implementing the Partner Server API
Details for how to implement the Partner Server API can be found in the API Reference and in the Partner server guide. The API allows Google to get the most up-to-date pricing and availability information from partners, and will be called by Google to:
- Generate a cache for returning prices quickly.
- Get the latest pricing when a user clicks into a specific itinerary.
Implementing the Partner Server API is required if the partner would like prices to be surfaced by Google.
3.2. API validation & testing
Once your API implementation is near completion and the service implementing it is up and running, please reach out to transport-help@google.com with the server information so we can start validating your implementation.
In the future, we plan to offer automated tooling for validating your API implementation, but this is not available yet.