subhuman/trippy-vvs-proxy repository overview

⁠Trippy VVS Proxy

Trippy VVS Proxy is a proxy server which wraps the infamous VVS (Verkehrsverbund Stuttgart - public transportation in Stuttgart) API in a REST environment.

The entire wrapper got reverse engineered using the official frontend⁠ of the VVS page.

Working with this API is a huge pain since it passes its entire payload using URL parameters while many of these are even obsolete.

The official API also does not support any CORS requests which is the actual reason why this project was created.

This project aims to give the user a very streamlined, and easy way to deal with said API.

⁠Live demo

You can use a live version of this proxy over at: https://trippy-vvs-proxy.subhuman.services.

⁠Installation

⁠Using your own server:

docker pull subhuman/trippy-vvs-proxy
docker run -d -p <your-port>:3000 subhuman/trippy-vvs-proxy

⁠For local development:

• Clone the repository

git clone
cd trippy-vvs-proxy

• Install and run the proxy

npm install
npm run dev

• Build the image

docker build -t <your-name> .

• Run the image

docker run -d -p <your-port>:3000 <your-name>

⁠API documentation

⁠GET /location/{search?}

search: String

Use this route to find your desired stop. The trip request needs stop ID which is a string made of letters, numbers and colons.

For example for Stuttgart Main Station: de:08111:6118

All stops that match the search query parameter will be listed in a locations array. Each location is an object containing the ID we need for the trip request. There is also matchQuality property which depicts how likely this location is the one the user is searching for.

⁠GET /trip/{origin}/{destination}

origin: stopID destination: stopID

This route will initiate a trip request from the origin to the destination. Both values need to be stop IDs.

The legs array in the response will include a stopSequence array which lists all stops in their appearing order on the track.

The transportation property includes everything we know about the train.

We also have the estimations of delays for arrivals and departures in their respective origin and destination properties.

Since this route does not need any date or time query parameters the API will default to today as the date and now as the time.

⁠GET /trip/{origin}/{destination}/{date}/{time?}

origin: stopID destination: stopID date: YYYYMMDD time: hhmm

This route will accept two more parameters for date and time. Using them can the API responds with trips on the given date and the given time. The time property is optional which will then default to the current time.

⁠License

MIT