The underlying APIs have a low rate limit, so please consider using db-vendo-client directly.

You can also use db-vendo-client yourself as a replacement, it covers most of the use cases served by db-rest, but the underlying APIs seem to have a much lower rate limit.

(This also applies to v5.db.transport.rest.)

Please use the successor, v6.db.transport.rest. It returns data in the format of hafas-client@6, so you will have to make minor adjustments. Check out the API documentation.

Please use the successor, v6.vbb.transport.rest. It returns data in the format of hafas-client@6, so you will have to make minor adjustments. Check out the API documentation.

Please use the successor, v6.bvg.transport.rest. It returns data in the format of hafas-client@6, so you will have to make minor adjustments. Check out the API documentation.

Just works just like its predecessor v5.bvg.transport.rest, but it returns data in the hafas-client@6 format (there are only minor changes compared to hafas-client@5 though).

Eventually I will shut off v5.bvg.transport.rest, so please try to migrate within the next 6 months.

Just works just like its predecessor v5.db.transport.rest, but it returns data in the hafas-client@6 format (there are only minor changes compared to hafas-client@5 though).

Eventually I will shut off v5.db.transport.rest, so please try to migrate within the next 6 months.

Just works just like its predecessor v5.vbb.transport.rest, but it returns data in the hafas-client@6 format (there are only minor changes compared to hafas-client@5 though).

Eventually I will shut off v5.vbb.transport.rest, so please try to migrate within the next 6 months.

• v5.bvg.transport.rest
• v5.db.transport.rest
• v5.vbb.transport.rest

Consider using their official API(s) instead.

The same applies to v0.hamburg-gtfs-rt.transport.rest which was based on the same underlying HAFAS API.

• v5.bvg.transport.rest
• v5.db.transport.rest
• v5.hvv.transport.rest
• v5.vbb.transport.rest

Currently, it provides data for the Zielona Góra region, but the idea is to extend it to other areas in Poland as well.

Please use the successor, v5.hvv.transport.rest. It returns data in the format of hafas-client@5, so you will have to make minor adjustments. Check out the API documentation.

Please use the successor, v5.bvg.transport.rest. It returns data in the format of hafas-client@5, so you will have to make minor adjustments. Check out the API documentation.

Please use the successor, v5.vbb.transport.rest. It returns data in the format of hafas-client@5, so you will have to make minor adjustments. Check out the API documentation.

Please use the successor, v5.db.transport.rest. It returns data in the format of hafas-client@5, so you will have to make minor adjustments. Check out the API documentation.

Please use the successor, v5.hvv.transport.rest. It returns data in the format of hafas-client@5, so you will have to make minor adjustments. Check out the API documentation.

Please use the successor, v5.bvg.transport.rest. It returns data in the format of hafas-client@5, so you will have to make minor adjustments. Check out the API documentation.

Please use the successor, v5.vbb.transport.rest. It returns data in the format of hafas-client@5, so you will have to make minor adjustments. Check out the API documentation.

Please use the successor, v5.db.transport.rest. It returns data in the format of hafas-client@5, so you will have to make minor adjustments. Check out the API documentation.

Just like its predecessor 1.hvv.transport.rest, it provides data for Hamburg public transport (HVV). The API returns data in the format of hafas-client@5. Check out the API documentation.

New features of this API:

• new features of hafas-client@4 & hafas-client@5 (mostly more detailed responses)
• new /radar route
• new /stops/reachable-from route
• /arrivals//departures & /journeys: pagination support via Link headers
• better caching support: strong ETags & Last-Modified headers

Just like its predecessor 2.bvg.transport.rest, it provides data for Berlin public transport (BVG). The API returns data in the format of hafas-client@5. Check out the API documentation.

New features of this API:

• new features of hafas-client@4 & hafas-client@5 (mostly more detailed responses)
• new /radar route
• new /stops/reachable-from route
• /arrivals//departures & /journeys: pagination support via Link headers
• better caching support: strong ETags & Last-Modified headers

Note: Because BVG's HAFAS system beneath this API is frequently down, consider using v5.vbb.transport.rest; Both have almost exactly the same data.

Just like its predecessor 3.vbb.transport.rest, it provides data for Berlin & Brandenburg public transport (VBB). The API returns data in the format of hafas-client@5. Check out the API documentation.

New features of this API:

• new features of hafas-client@4 & hafas-client@5 (mostly more detailed responses)
• new /radar route
• new /stops/reachable-from route
• /arrivals//departures & /journeys: pagination support via Link headers
• better caching support: strong ETags & Last-Modified headers
• more consistent & intuitive routes for stops/stations & lines search/info

Just like its predecessor 2.db.transport.rest, it provides data for Deutsche Bahn. The API returns data in the format of hafas-client@5. Check out the API documentation.

New features of this API:

• new features of hafas-client@4 & hafas-client@5 (mostly more detailed responses)
• new /radar route
• new /stops/reachable-from route
• /arrivals//departures & /journeys: pagination support via Link headers
• better caching support: strong ETags & Last-Modified headers
• more consistent & intuitive routes for stops/stations search/info

• 1.hvv.transport.rest
• 2.db.transport.rest
• 2.bvg.transport.rest
• 3.vbb.transport.rest

The rate limit works by IP address. The endpoint will respond with 429 Too Many Requests as long as you are above the threshold.

Please use the successor, 2.bvg.transport.rest. It returns data in the format of hafas-client@4, so you will have to make minor adjustments.

Please use the successor, 3.vbb.transport.rest. It returns data in the format of hafas-client@4, so you will have to make minor adjustments.

As the underlying HAFAS endpoints beneath 3.vbb.transport.rest and 2.bvg.transport.rest both cover almost all of Berlin & Brandenburg, they are pretty much equivalent.

Check the docs at derhuerst/bvg-rest.

It returns almost exactly the same data as 2.vbb.transport.rest, but in the output format of hafas-client@3, so you will have to make minor adjustments.

I won't run the 2.vbb.transport.rest endpoint for the time being. If you want to use consume VBB data using JavaScript, use vbb-hafas (the lib behind the API) directly, otherwise host your own vbb-rest instance for now.

@juliuste and I have met recently with VBB. We were able to communicate:

• our desire to keep this API running,
• that the 2.vbb.transport.rest endpoint is not responsible for the amount of traffic they've received with a hafas-client User-Agent,
• that an open GTFS RT feed would solve many issues for both parties.

In your app, you could now show where to enter a train in order to have the best transfer path at the arrival station. vbb-journey-ui a preliminary UI for this.

Check the vbb-hafas docs with details about the markup.

The API should be compatible with 1.db.transport.rest in many aspects. Check the docs at juliuste/meinfernbus-rest.