MBTA

1. Visit the MBTA Developer Portal and sign up — email plus an organization name is enough.
2. Once verified, the portal shows your API key on the dashboard.
3. Copy the key value.

In the Ingest UI under Connectors → MBTA, paste the key. Ingest stores it in AWS Secrets Manager under the key token. The runtime sends it as the x-api-key request header on every call.

Without a key, the MBTA API enforces 20 req/min globally — too low for any production sync. With a registered key, the limit is 1,000 req/min (about 16 req/sec). The Ingest runtime dispatches at 8 req/sec by default and uses AIMD backoff on 429 responses.

The API returns JSON:API-shape envelopes — every response has a top-level data array (or single object) containing resources of the form {id, type, attributes, relationships}. The connector flattens attributes into your Iceberg mart's columns.

Errors with status 400 (malformed request — usually missing a required filter), 403 (key revoked / disabled), 404 (no resource matches), or 406 (unsupported response type) are treated as fatal — fix the cause before retrying.

The MBTA endpoints fall into a few groups:

• Static reference data — routes, stops, lines, route_patterns, services, shapes, trips, facilities. Refresh daily or weekly; this is the schedule and network topology.
• Schedule data — schedules. Pre-published time-of-day plans tied to a service. Best refreshed when the published schedule rotates (a few times per year), unless you're modeling daily expected vs actual.
• Real-time — predictions, vehicles, live_facilities, alerts, stop_events. Dynamic feeds you'd pull on a frequent schedule for live dashboards. Note that some of these endpoints (e.g. predictions, schedules) require a filter and will return 400 without one — your generator model handles the filter parameter.