Reference · built on requestCommons signalTransit, roads & mobility

Mobility Database

Catalog of GTFS, GTFS Realtime, and GBFS feeds worldwide, with dataset history and validation reports, from MobilityData.

About

The Mobility Database is an open catalog hosted and maintained by MobilityData, the non-profit dedicated to open transportation data standards. It lists over 6000 GTFS, GTFS Realtime, and GBFS feeds in over 99 countries. Each entry records the provider, location, producer URL, authentication needs, license, and status of one feed. For GTFS feeds it keeps a mirrored copy of every dataset it has downloaded and the report from the Canonical GTFS Schedule Validator. Feeds are checked for updates every day. The REST API at api.mobilitydatabase.org serves the catalog as JSON, and the catalog metadata is released under Creative Commons CC0.

An operator uses it to find the feed for a city, read its access rules, and watch whether that feed stays reachable and valid before a schedule or arrival job depends on it.

This is a reference listing. It documents what Fibric would read from Mobility Database and what it could propose, based on the publisher's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Feeds from GET /v1/feeds, /v1/gtfs_feeds, /v1/gtfs_rt_feeds, and /v1/gbfs_feeds, filtered by provider, producer_url, country_code, subdivision_name, and municipality
  • Per feed: id, data_type, provider, status (active, deprecated, inactive, development, or future), feed_contact_email, redirects to a replacement feed, and external_ids
  • source_info per feed: producer_url, is_producer_url_unstable, authentication_type 0, 1, or 2, authentication_info_url, and license_url
  • entity_types on GTFS Realtime feeds (vp, tu, sa) with the GTFS feeds they reference; versions and system_id on GBFS feeds
  • Datasets per GTFS feed from /v1/gtfs_feeds/{id}/datasets: hosted_url, downloaded_at, hash, service date range, agency_timezone, and bounding_box
  • Validation history from /v1/gtfs_feeds/{id}/validation_reports: validated_at, validator_version, error, warning, and info counts, and links to the JSON and HTML report
  • Availability checks from /v1/gtfs_feeds/{id}/availability, and /v1/search over provider, location, and feed name

Proposed actions

Read-only. This feed informs operators; it changes nothing.

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Pick the right transit feed for a property

    Shuttle Timing needs the local agency's GTFS Realtime feed. The catalog returns the feeds inside your bounding box with their producer URLs and authentication rules, and the operator proposes which one to wire up.

    With Shuttle Timing

  • Catch a feed going stale before a schedule job does

    Data Freshness reads availability checks and each dataset's downloaded_at, then proposes a notice when a feed you rely on fails its checks or has run past its service date range.

    With Data Freshness

  • Move off a deprecated feed

    Integration Health watches status and redirects on the feeds you consume and proposes a switch to the target_id feed when the old one is marked deprecated or inactive.

    With Integration Health

Requirements

  • A Mobility Database account, which is free, and its refresh token
  • country_code, municipality, or dataset_latitudes and dataset_longitudes values for the areas whose feeds you want
  • Credentials for any feed whose source_info reports authentication_type 1 or 2; the feed producer issues those, not MobilityData
  • A downstream reader for the GTFS, GTFS Realtime, or GBFS data itself; the catalog points to feeds rather than serving vehicle positions
Authentication
A Bearer access token from POST /v1/tokens/access, generated from the long-lived refresh token shown in your Mobility Database account after sign-up; access tokens expire after one hour.

Limits

  • The API returns at most 3500 feeds per call and at most 100 validation reports or availability checks per call; page with offset
  • Datasets, validation reports, and availability checks exist only for GTFS feeds; GTFS Realtime and GBFS feeds are cataloged, not mirrored
  • The reliability seal, validation history, and continuous coverage endpoints are tagged beta in the API specification
  • This listing is a reference. Fibric builds the integration under a managed deployment when you request it

Access and pricing

Reference listing. Public feed access is separate from Fibric integration. If you request this feed, your quote covers the build, usage, and support.

Request Mobility Database ↗

Questions and answers

Does the API serve vehicle positions or trip updates?
No. It catalogs feeds. A GTFS Realtime entry lists its entity_types (vp for vehicle positions, tu for trip updates, sa for service alerts) and its producer_url. You read the realtime data from that URL, following the authentication_type and authentication_info_url the entry reports.
How current are the datasets and validation reports?
MobilityData checks each GTFS feed for a new dataset once a day and stores the new file with its hash, downloaded_at, and a report from the Canonical GTFS Schedule Validator. The catalog CSV on GitHub is updated one to three times a month; the API reads the database directly.
What license covers the catalog?
MobilityData releases the catalog metadata under Creative Commons CC0. Each feed's own data carries its producer's terms, which the entry's license_url points to. The API and catalog code are under the Apache 2.0 license.
Ask about Mobility Database

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.