Helsinki Open Transit Data Guide — How Apps Track Buses in Real Time

June 20, 2026 — Technical guide for developers and transit enthusiasts

Why Helsinki's Transit Data Matters

Helsinki has one of the most open and developer-friendly public transport data ecosystems anywhere. HSL publishes real-time vehicle positions, schedules, and route data under open licenses — the same data that powers the apps used by over a million daily passengers.

This openness has spawned a rich ecosystem of third-party transit apps, research projects, and data visualizations. Whether you're building a tracking app, a research tool, or just curious how your bus app knows where the next vehicle is, this guide covers the core data sources, APIs, and integration patterns.

Finland's commitment to open transit data is genuinely exceptional, even by Nordic standards. HSL's real-time GTFS-RT feeds update vehicle positions every few seconds, MQTT streams allow push-based updates, and the Digitransit GraphQL API provides a unified query interface across all Finnish transit authorities. Together, they form one of the most complete urban mobility data stacks out there.

The Data Stack: Three Layers

1. Static Data — GTFS (General Transit Feed Specification)

GTFS is the foundation — schedules, routes, stops, and timetables. HSL publishes static GTFS data that defines every route, stop, and scheduled departure in the network. Think of it as the "map" layer that tells apps where buses should go and when.

Key files in a GTFS feed:

• stops.txt — Every bus stop, tram stop, metro station, and ferry terminal with coordinates
• routes.txt — All transit lines (e.g., bus 550, tram 3, metro M1)
• trips.txt — Individual vehicle journeys along routes at specific times
• stop_times.txt — When each trip arrives at each stop
• shapes.txt — Geographic path each route follows (so you can draw lines on a map)

Get it: HSL GTFS data is available at Transitland and HSL's open data portal.

2. Real-Time Data — GTFS-RT (Real-Time)

GTFS-RT is the live layer — actual vehicle positions, delay information, and service alerts. This is what lets apps show a bus moving on the map instead of just its scheduled time.

HSL provides three GTFS-RT feeds:

Feed Type	What It Provides	Update Frequency
Vehicle Positions	GPS coordinates of every active bus, tram, metro, ferry, and train — including bearing (direction), speed, and current stop	~2–5 seconds
Trip Updates	Predicted arrival/departure times for every stop on every active trip — including delays and early arrivals	~10–30 seconds
Service Alerts	Disruptions, detours, cancelled trips, and planned maintenance	As needed

Why this matters: Vehicle positions are the killer feature. Instead of showing "Bus 550 — 3 min" (an estimate), you can plot the actual bus location on a map. No more watching a bus drive past while your app says "arriving in 2 minutes."

The protocol buffers format (.pb) is compact and efficient — a typical position update from HSL is under 1KB per vehicle. For a mobile app, minimal data usage even with frequent polling.

3. Push Stream — MQTT (Message Queue Telemetry Transport)

MQTT is HSL's high-frequency data stream. Unlike GTFS-RT (which requires polling), MQTT pushes updates to subscribers in real time. It's the same tech that powers IoT sensors and connected cars — lightweight, fast, and built for constant data flow.

HSL's MQTT broker publishes vehicle position updates for the entire fleet. Each vehicle emits a JSON message with:

• Vehicle ID and route number
• GPS coordinates (latitude, longitude)
• Speed and heading (direction of travel)
• Current stop and next stop
• Delay status (on time, early, delayed)
• Vehicle type (bus, tram, metro, ferry, train)
• Door status (open/closed)

Topic structure: /hfp/v2/journey/ongoing/vp/{operator}/{vehicle}/...

For a tracking app, MQTT is ideal — you receive updates as they happen, no polling overhead. Reitti uses MQTT to achieve its 3-second position update interval across the entire HSL fleet.

The Unified API — Digitransit GraphQL

Digitransit is the national platform that unifies transit data across Finland. Its GraphQL API lets you query any Finnish city's transit data through a single endpoint — routes, stops, trip planning, and real-time positions.

Why GraphQL matters: Instead of fetching bloated REST responses, you request exactly the fields you need. For a mobile app, faster load times and less data consumption.

Example query — get real-time vehicle positions near a point:

query {
  vehiclesByBbox(
    minLat: 60.17, minLon: 24.92,
    maxLat: 60.18, maxLon: 24.95
  ) {
    id
    lat lon
    heading speed
    route { shortName mode }
    trip { tripHeadsign }
  }
}

Get started:

• GraphQL endpoint: https://api.digitransit.fi/routing/v1/routers/hsl/index/graphql
• Interactive explorer: api.digitransit.fi
• Documentation: digitransit.fi/en/developers

Building a Real-Time Tracking App: Architecture Overview

Here's how a production tracking app like Reitti integrates these data sources:

1. Bootstrap: Load static GTFS data at startup — route geometries, stop locations, schedule data. Cache locally for offline use and fast rendering.
2. Subscribe: Connect to HSL's MQTT broker. Receive vehicle position updates in real time for all active vehicles in the region.
3. Render: Plot vehicles on a map (Google Maps, Mapbox, or OpenStreetMap). Update markers every time MQTT delivers a position update.
4. Enrich: Cross-reference vehicle IDs with GTFS trip data to show route numbers, destinations, and stop sequences.
5. Predict: Combine real-time trip updates with schedule data to estimate arrival times at upcoming stops.
6. Notify: When a user sets a stop alert, monitor vehicle positions and fire a notification when a vehicle approaches the user's chosen stop.

Key technical decisions:

• MQTT vs polling: MQTT is more efficient for continuous tracking — you receive updates instead of requesting them. But it requires a persistent TCP connection.
• Client-side rendering: Vehicle positions change every 2–3 seconds. Smooth map animations need efficient marker management — recycle marker objects, use clustering for zoomed-out views.
• Battery optimization: MQTT keepalive pings + GPS + map rendering = battery drain. Use adaptive update frequencies — faster when the app is active, slower in background.
• Data volume: HSL operates ~1,300 vehicles during peak hours. Each position update is ~200 bytes. At 3-second intervals, that's roughly 260KB/s from MQTT alone — fine on 4G/5G, but worth optimizing for background mode.

Other Finnish Cities with Open Transit Data

While HSL (Helsinki region) has the most sophisticated data stack, other Finnish cities also provide open transit data through Digitransit or direct GTFS feeds:

City/Region	Transit Authority	GTFS Available	Real-Time	MQTT
Helsinki region	HSL	✅	✅ GTFS-RT	✅
Tampere	Nysse	✅	✅ GTFS-RT	✅
Turku	Föli	✅	✅ GTFS-RT	✅
Oulu	OSL	✅	✅ GTFS-RT	—
Jyväskylä	Linkki	✅	✅ GTFS-RT	—
Lahti	LSL	✅	✅ GTFS-RT	—

Most Finnish cities use the same data formats and can be accessed through the same Digitransit API — so building a multi-city tracking app is totally feasible by just switching the GraphQL router parameter.

Open Data Resources & Links

Resource	Description	URL
HSL Open Data Portal	Official HSL data page — GTFS, GTFS-RT, MQTT	hsl.fi/en/hsl/open-data
Digitransit Developer Portal	National transit API — GraphQL, routing, geocoding	digitransit.fi
Transitland	Global GTFS feed aggregator — includes HSL	transit.land
GTFS.org	The GTFS specification and best practices	gtfs.org
HSL Developer Community	GitHub org with tools and examples	github.com/HSLdevcom
OpenStreetMap Finland	Community-mapped transit infrastructure	OSM Finland transit

FAQ for Developers

Is an API key required?

Nope. HSL's GTFS-RT feeds, MQTT broker, and Digitransit API are all publicly accessible without registration. Rate limits exist but they're generous enough for production apps.

What's the latency?

MQTT position updates typically arrive within 1–2 seconds of the vehicle broadcasting them. GTFS-RT polling has 10–30 second update cycles depending on the feed.

Can I use this data commercially?

Yes. HSL's open data is licensed under Creative Commons Attribution 4.0 (CC BY 4.0). Use it in commercial apps — just attribute HSL as the source.

How many vehicles are tracked simultaneously?

During peak hours, HSL tracks about 1,300 vehicles across buses, trams, metros, ferries, and trains. The MQTT stream handles this volume without noticeable lag.

What about the new light rail (pikaraitiotie)?

Line 15 (Raide-Jokeri) is fully integrated into HSL's data feeds — it shows up as a vehicle type in both GTFS-RT and MQTT, sharing the same data structure as trams.

Related articles:

• Helsinki Public Transport Guide 2026
• Best Public Transport Apps in Finland 2026
• Helsingin joukkoliikenneopas 2026 (FI)