Connector support

Separate supported local paths from future integration candidates.

Open Transit RT uses explicit adapters for vehicle telemetry, prediction, validation, monitoring, and discovery workflows. Review configured instances separately from examples before connecting real systems.

Works Today For Local Or Self-Hosted Evaluation

AreaSupported pathWhere to review
Vehicle dataCSV replay, HTTP polling, webhook sidecar, generic JSON transform, authenticated telemetry POST./admin/operations/connectors/vehicle-avl
PredictionDeterministic built-in predictor and external HTTP predictor adapter with shadow/fail-closed metadata./admin/operations/connectors/prediction
ValidationMobilityData static GTFS and GTFS Realtime validator wrappers when tooling is installed./admin/operations/connectors/validators
Monitoring and exportNo-send monitoring/export setup with redacted digest metadata./admin/operations/connectors/monitoring
Discovery/public/feeds.json readiness, license/contact metadata, and public URL warnings without portal automation./admin/operations/connectors/discovery

Planned Or Candidate Work

Prediction engines

TheTransitClock and other predictors are candidates behind the prediction adapter. They are not bundled runtime dependencies or ETA-quality proof.

Vendor AVL and SIRI-shaped systems

Real vendor payloads and SIRI bridges need explicit adapters, redaction, credential handling, and deployment-owner review.

GTFS QA extensions

GTFS-Flex, GTFS-ride, GTFS-Pathways, and GTFS-Fares v2 are future QA areas, not current dispatch, booking, fare-payment, or analytics features.

Aggregator and consumer preparation

Transitland, Mobility Database, OpenTripPlanner, and OneBusAway checks remain preparation or investigation until implemented and tested.

Limits

Connector documentation does not prove compatibility with named vendors, certified hardware support, production AVL reliability, consumer acceptance, compliance, hosted service availability, production readiness, SLA coverage, or ETA quality.