Metro Transit · Rate Limits

Metro Transit Rate Limits

Metro Transit does not publish numeric rate limits or require an API key for its open-data GTFS, GTFS-realtime, and NexTrip / REST endpoints. The published guidance is that GTFS-realtime feeds refresh every 5 seconds (so polling faster than that is wasted) and that schedule data updates weekly (Saturdays). Consumers are expected to use HTTP conditional requests (Last-Modified / If-Modified-Since) rather than re-downloading the GTFS zip. There is no documented 429 throttle behavior; abusive volume would be addressed informally if it impacted service.

Metro Transit Rate Limits is the machine-readable rate-limit profile for Metro Transit on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 3 rate-limit definitions, measuring requests_per_second and requests_per_week.

The profile also includes 4 backoff/retry policies defined and response codes documented for serviceUnavailable.

Tagged areas include Minneapolis, Minnesota, Public Transportation, Real-Time, and Transit.

3 Limits
MinneapolisMinnesotaPublic TransportationReal-TimeTransitRate Limiting

Limits

GTFS-realtime poll cadence public
requests_per_second
recommended cadence 1 poll per 5 seconds (feed refresh interval)
Feeds (tripupdates.pb, vehiclepositions.pb, alerts.pb) refresh every 5 seconds; polling faster yields stale duplicates.
GTFS static refresh public
requests_per_week
recommended once per Saturday refresh (use Last-Modified)
Static schedules are published weekly on Saturdays; honor Last-Modified / If-Modified-Since to avoid unnecessary downloads.
REST API public
requests_per_second
no documented hard limit; observe fair-use
Public REST endpoints have no published rate limit; expected consumption is at human-driven cadence (e.g. one stop departure board update per few seconds per active user).

Policies

Backoff Strategy
On transient 5xx responses, back off exponentially with jitter and resume normal polling once successful responses return.
Conditional Requests
Use HTTP Last-Modified / If-Modified-Since for the GTFS zip and other slowly-changing resources to minimize bandwidth and load on the public service.
Refresh Cadence
Match polling cadence to the feed's natural refresh interval — 5 seconds for GTFS-realtime, weekly for static schedules — rather than polling at arbitrary frequency.
Open Data Etiquette
Identify your User-Agent, attribute Metro Transit as the data source where appropriate, and avoid aggressive scraping that could degrade service for other public-data consumers.

Sources