GTFS Realtime Feed Service

Each agency below publishes up to three types of GTFS-Realtime feed messages. Expand an agency card to see the ready-to-use endpoint URLs for each feed type. No authentication is required for public feeds.

How to request a feed: Send an HTTP GET to the URL shown in each agency card:

GET /GtfsProtoBuf?FeedLabel={Agency}&FeedType={Type}

The response is a binary GTFS-Realtime Protocol Buffer message (Content-Type: application/x-protobuf). Each feed type serves a distinct purpose:

• VehiclePositions — Live GPS coordinates and occupancy for active vehicles. Used to animate bus icons on maps in real time.
• TripUpdates — Arrival and departure time predictions per stop, powering “Next Bus in X minutes” displays and journey planners.
• ServiceAlerts — Disruption notices, route detours, and rider advisories surfaced as alert banners within consumer apps.

Polling cadence: Feeds are updated as new data arrives from the agency — update frequency is data-driven, not on a fixed-interval. Typical update windows by feed type:

• Vehicle Positions — sub-second up to every 15 seconds. Based on typical vehicle activity and GPS update rates.
• Trip Updates — every 5–15 seconds. Based on typical trip patterns and schedule adherence.
• Service Alerts — every 10–20 seconds. Based on typical service disruption patterns and alert propagation times.

If a feed type has no data or has not received an update within the last 28 seconds, it is automatically republished with a updated header timestamp, so consumers can be confident they are always receiving the most current snapshot — even when that snapshot is empty.

Efficient caching: Each response includes ETag and Last-Modified headers. Send If-None-Match or If-Modified-Since on subsequent requests — the service returns 304 Not Modified when the feed has not changed, saving bandwidth and parse time. On a 304, continue using your previously parsed payload.

Data integrity: Each response is an authoritative, atomic snapshot of all entities for that feed type at the given timestamp. Replace your full local state on every successful fetch — partial updates are never issued.

For complete technical details including HTTP status codes, Protocol Buffer specification, and feed encoding, see the Feed Publishing & Practices page.