API (v1)Overview (deprecated)
- Service Advisories
- Stop Features
- Stop Schedules
- System Messages
- Trip Planner
Winnipeg Transit's Open Data Web Service provides a way for you to retrieve live information about Winnipeg Transit's services by sending GET requests to URLs like: https://api.winnipegtransit.com/web-service-path?and=parameters
Data is returned in XML format by default. JSON data can be requested by appending ".json" to the path. Returned data is subject to change throughout the day. This is because it represents a real-time picture of what is currently happening on the streets, with information about our city-wide service status, which individual buses are delayed and by how much, the estimated arrival times of buses at stops, and more.
Look here for an example of how to use this API.
Static Schedule Data
All of our static schedule data (as opposed to the real-time data provided by our Open Data Web Services) is also available for download in a single file. This file is updated daily and adheres to the General Transit Feed Specification.
Once you've signed up for an account, you will be given an API key. This key must be included in all requests you make, like so: https://api.winnipegtransit.com/v1/stops/10064?api-key=YOUR-API-KEY
Winnipeg Transit's Open Data Web Service throttles requests to prevent its servers from being overloaded. Each API key is allowed 100 requests per IP address per minute.
To specify the version of our API you wish to use you can prepend the version key to the beginning of a request, like so:
A Web service's requests are typically organized into three different types: identity, filter, and wildcards. These generally define the type of response you'll get.
are shown in the API documentation for each available web service if you are logged in. The API Explorer uses your
API key to show results of web service requests. The explorer allows you to modify parameters and try out
the various queries provided by the API.
Examples of invalid URLs are displayed in red italics.
Identity queries return a single result. They're typically accessed by specifying the ID of the desired resource.
Filter queries are so named because the results returned are filtered according to specified URL parameters. You can, for example, filter stop results according to a coordinate point and radius — only stops which fall within that radius will be returned.
Wildcard queries are queries which do their best to match whatever string you provide. They're useful for doing things like quickly looking up resources based on a name. Like filter queries, wildcard queries potentially return multiple results.
Common URL Parameters
These URL parameters are common to all services and all URL types:
The style of names to return.
You can retrieve JSON results for any web service by adding ".json" to the end of the path (before the URL parameters).