KVB APIkvb.koeln ↗
Get real-time departure schedules and stop data for Cologne's KVB transit network. Search stops by name, resolve IDs, and fetch live delays and platform info.
What is the KVB API?
The KVB Cologne API provides 2 endpoints for querying real-time transit data from the Kölner Verkehrs-Betriebe network, covering trams (Stadtbahn), buses, and regional rail. Use search_stops to find any stop in the network by name and retrieve its ID, coordinates, and served lines. Use get_departures to pull live departure or arrival boards with scheduled times, real-time times, delay in minutes, and platform details.
curl -X GET 'https://api.parse.bot/scraper/ebd18bf3-f469-4e15-9143-226dfe76fec5/search_stops?query=Neumarkt&max_results=5' \ -H 'X-API-Key: $PARSE_API_KEY'
Search for transit stops/stations by name. Returns matching stops with their IDs, coordinates, and available transit lines. Useful for resolving a human-readable name to a stop ID required by get_departures. Results may span the entire NRW transit network, not just Cologne city limits.
| Param | Type | Description |
|---|---|---|
| queryrequired | string | Stop name to search for (e.g. 'Neumarkt', 'Dom/Hbf', 'Rudolfplatz') |
| max_results | integer | Maximum number of results to return |
{
"type": "object",
"fields": {
"query": "string - the search query used",
"stops": "array of Stop objects with name, ext_id, lid, type, coordinates, and lines",
"total": "integer - number of stops returned"
},
"sample": {
"data": {
"query": "Neumarkt",
"stops": [
{
"lid": "A=1@O=Köln Neumarkt@X=6948329@Y=50935667@U=1@L=900000002@B=1@p=1780990549@",
"name": "Köln Neumarkt",
"type": "S",
"lines": [
{
"name": "1",
"category": "Stadtbahn"
},
{
"name": "3",
"category": "Str"
}
],
"ext_id": "900000002",
"coordinates": {
"latitude": 50.935667,
"longitude": 6.948329
}
}
],
"total": 10
},
"status": "success"
}
}About the KVB API
Stop Search
The search_stops endpoint accepts a query string (e.g. 'Neumarkt', 'Dom/Hbf', 'Rudolfplatz') and returns an array of matching stop objects. Each stop includes a human-readable name, an ext_id for use in subsequent calls, a lid (location identifier), a type field indicating the stop category, lat/lon coordinates, and a list of lines serving that stop. The total field tells you how many stops matched. Use max_results to cap the response when you only need the top match.
Real-Time Departure and Arrival Boards
The get_departures endpoint resolves a stop either by stop_name or by stop_id (the ext_id from search_stops) — one of the two is required. Set type to 'DEP' for departures or 'ARR' for arrivals; it defaults to departures when omitted. Each item in the departures array carries line, category, direction, scheduled_time, realtime_time, delay_minutes, platform, date, and stop_name. The delay_minutes field is especially useful for detecting disruptions or catching connections programmatically.
Network Coverage
The API covers the full KVB network in Cologne, including numbered Stadtbahn tram lines (e.g. lines 1, 3, 7, 18), city bus routes, and regional rail services that stop at KVB-tracked stations. Stop IDs are stable identifiers suitable for persistent configuration in apps and dashboards. The lines array on each stop result lets you quickly filter stops by which specific routes serve them.
The KVB API is a managed, monitored endpoint for kvb.koeln — not a raw scraper you maintain. Every endpoint is automatically health-checked on a schedule, and when kvb.koeln changes and a check fails, the API is automatically queued for repair and re-verified. It is built to keep working as the site underneath it changes.
This isn't an official kvb.koeln API — it's an independent, maintained REST wrapper over public data. Where the source has no official API (or only a limited one), Parse gives you a stable contract over a source that never promised one, and keeps it current. Need a new endpoint or field? You can revise it yourself in plain English and the agent rebuilds it against the live site in minutes — contributing the change back to the shared API is free.
Will this API break when the source site changes?+
Is this an official API from the source site?+
Can I fix or extend this API myself if I need a new endpoint or field?+
What happens if I call an endpoint that has an issue?+
- Display a live departure board for a specific KVB stop in a transit app, showing line, direction, and real-time delay.
- Alert commuters when
delay_minutesexceeds a threshold on their regular tram or bus line. - Resolve a user-typed stop name to a canonical
ext_idviasearch_stops, then persist it for repeatedget_departurescalls. - Build a multi-stop arrival monitor for a Cologne venue, aggregating inbound services across several nearby stops.
- Filter stops by the
linesarray to find all KVB stations served by a particular Stadtbahn line. - Power a kiosk display showing platform numbers and scheduled vs. real-time departure times for passengers.
| Tier | Price | Credits/month | Rate limit |
|---|---|---|---|
| Free | $0/mo | 200 | 5 req/min |
| Hobby | $30/mo | 1,000 | 20 req/min |
| Developer | $100/mo | 5,000 | 100 req/min |
| Team | $300/mo | 20,000 | 300 req/min |
| Company | $1,000/mo | 100,000 | 500 req/min |
Each endpoint has a fixed posted price per successful call — most fall between 1 and 10 credits — shown on this API's page before you run it. Exceeding the rate limit returns a 429 response. Authenticate with the X-API-Key header.
Does KVB provide an official developer API?+
What exactly does `get_departures` return, and how do scheduled vs. real-time times differ?+
scheduled_time (the timetabled time) and realtime_time (the live predicted time). The delay_minutes field is the numeric difference between them, making it straightforward to detect late services without computing the diff yourself. Platform and stop name are also included per departure.Does the API cover trip planning or route calculation between two stops?+
Can I retrieve historical departure data or only live schedules?+
How do I look up a stop when I only know part of its name?+
query parameter of search_stops. It returns all matching stops with their ext_id, coordinates, and served lines. You can then use the ext_id directly in get_departures via the stop_id parameter to avoid ambiguity from name-based lookups.