OpenStation is DB InfraGO's single source of truth for open data on passenger station infrastructure in Germany. It provides data in accordance with European standards (NeTEx, SIRI coming soon), and represents our so-called Inventory of Assets as required by the EU's TSI-PRM regulation on the accessibility on passenger rail infrastructure.
This documentation provides an introduction to the two ways of obtaining OpenStation data and presents a brief overview of the data model used in the API. Furthermore, it outlines our approach to API endpoint stability and breaking changes. Please read that section carefully if you plan to use our API in a production system.
A note before we dive into the details: OpenStation is currently in an open beta phase, which is – as of August 2025 – planned to last until December 2025. This means that some elements of the “target data model” are not yet available at all stations. We are working on collecting that data in a timely manner.
OpenStation data can be obtained in two ways:
- Via Germany's Mobilithek (the country's national access point for open transportation data as mandated by EU legislation)
- Via DB's API Marketplace
Both of these sources offer advantages and disadvantages, which are documented below. However, TL;DR: For a permanent productive connection, we strongly recommend obtaining OpenStation data via the Mobilithek.
| Mobilithek | DB API Marketplace | |
|---|---|---|
| Advantages | No API credentials required, no request limits, high performance, bulk output, supports compression, longer stability guarantees (see section on breaking changes below) | Filter parameters (e.g. filtering the output by station id), pagination |
| Disadvantages | No filter parameters (just one plain XML dataset containing everything) | API credentials required, request limits, no bulk output (pagination required), no compression |
We intend DB API Marketplace with its additional filter parameters to be used for smaller, exploratory projects, while all other systems, especially large production deployments, should retrieve their data via the Mobilithek.
Obtaining data through Mobilithek is our recommended approach. You won't need any credentials (even though creating a dedicated subscription with credentials is possible and can be used to receive updates in case of breaking changes, see also: Stability and Breaking Changes).
You can obtain the OpenStation NeTEx dataset as follows:
curl --compressed 'https://mobilithek.info/mdp-api/mdp-conn-server/v1/publication/879076212433727488/file/noauth' > netex.xmlAs you might have noticed, this request contains a dataset ID assigned by Mobilithek. That ID is stable for now, but if we, for some unforeseen reason, have to re-register our dataset at any point in the future, the ID might change.
We therefore offer the following additional endpoint, which will always redirect to our latest Mobilithek dataset. We strongly recommend using it:
curl -L --compressed 'https://bahnhof.de/daten/netex' > netex.xmlPlease note that the library you use to send the request must support HTTP redirects (in case of curl, this is achieved by supplying the -L option).
Not implemented yet, coming soon.
To obtain OpenStation data through the DB API Marketplace, you first need to complete the following steps:
- Create a new user account here
- Create a new application here
- Store the credentials (
Client ID,Client Secret) you received when creating the application. You will need them to send requests. You can always (re-)generate additional credentials by navigating to Anwendungen → YOUR_APPLICATION. - In the catalog, search for OpenStation and follow the steps to add a subscription for the application you created before.
Given your Client ID and Client Secret, you can retrieve our OpenStation NeTEx dataset as follows:
curl 'https://apis.deutschebahn.com/db-api-marketplace/apis/open-station/v1/netex' \
-H 'DB-Client-ID: <YOUR_CLIENT_ID>' \
-H 'DB-Api-Key: <YOUR_CLIENT_SECRET>' > netex.xmlNot implemented yet, coming soon.
Coming soon.
We make every effort to avoid breaking changes in the API that would require the adaptation of code on the consumer side. Nevertheless, situations may arise that necessitate the implementation of such a change. We would therefore like to determine from the outset how and in what time frame we will announce and implement breaking changes should they become necessary.
We will announce breaking changes (as well as relevant new features) via the following channels:
- Email to all subscribers to our dataset in the Mobilithek. Even though you can consume our dataset without subscribing to it, or consume it via the DB API Marketplace, we strongly recommend you create a subscription in the Mobilithek nonetheless, as that allows us to notify you via email in case of a change.
- Issue in this GitHub repository. For everyone who can not or does not want to create subscriptions in the Mobilithek, we will also create issues to track breaking changes in this GitHub repository. You can receive notifications for these by watching this repo. Please note however, that you will receive notifications for all issues in this repository, not only those related to breaking changes.
Furthermore, all changes to the API will be documented in the changelog.
Depending on the type of breaking change and the data portal you choose, these are the lead times from announcement to implementation :
| Changes to the data model | Changes to the API / Transport Layer | |
|---|---|---|
| Mobilithek | 9 months | 6 months |
| DB API Marketplace | 9 months | 3 months |
Data in the API as well as the API documentation is released to the public domain (under the CC0 “license”). Source code for any supporting programmes in this repository is released under the APACHE 2.0 license.
If you have problems using the API, would like to point out errors or inconsistencies, or have any other feedback to share, please feel free to open an issue or contact us by email.
You're also invited to contribute directly by creating a pull request.
Note that, by participating in this project, you commit to the code of conduct, and agree to the release all of your contributions to the public domain (under the CC0 “license”, for changes to the API documentation), and under the APACHE 2.0 license (for code of any supporting programs in this repository), respectively.