Hi, this is mainly aimed at the developers of the API, i have a question regarding the app key…
I am currently writing a Windows application that uses TFL data to display all the trains on the underground live…and i am aware of the terms and conditions here:
However because i am writing a windows application and not a web application i will have to allow my users to download the program and install it, this means of course that unlike a web application i cannot easily update it once its out in the real world… i will of course provide major updates if and when needed.
So my question is, bearing this in mind, will i need my users to register and get there own key and use it in my program or can i release the program with just my own key with it which is how of course i am accessing the TFL data with it now.
I ask because eventually there could be a few hundred users or more all accessing the data using my key.
And i wouldn’t want them all to be suddenly kicked off the server.
For those that do not know what my program (it will be called: Underground Alive!) will look like in general (there are many options accessible via a right click menu to turn lines, station names and trains off and on, so this is just 1 screen) i will include a screen shot…
Anonymous access to our API is limited to 50 requests a minute. If you want to call the API more than that, you’ll need to subscribe to a “Product” which lets you bypass this limit with a subscription-key that you append to your requests. Customers are able to apply online here for the “500 requests a minute” Product which should cover most use-cases, but higher quotas are available upon request.
If your app requires less than 50 requests a minute it would not need a key and presumably TfL would accept that each user is independent. If not, and if you were permitted to distribute one key with the app, your “few hundred users” would exceed the 500 requests a minute limit for that key.
Isn’t this a bit the wrong way round? Surely, your Windows client app should be accessing data from your own server, which, in turn, uses your app key to access the API. That way, only you need to worry about that aspect.
The important thing here is that you should be caching the acquired data, so that multiple user requests need not result in multiple API calls
@ nickp, my program is using the TFL data directly like a website that uses it would, so why would i need my own server?
And i am not in a position to keep my own server up and running in any case, that would give me a whole new set of things to deal with that i just do not need for a free program.
Limit traffic requests up to a maximum of 500 calls per minute per data feed. TfL reserves the right to throttle or limit access to feeds when it is believed the overall service is being degraded by excessive use
Anything sent to a browser on a website can be accessed by end users, thanks to the powerful developer tools available in web browsers, and means someone could get your API key and start making a large number of requests “on your behalf”, which would lead to your account being rate-limited or potentially even block-listed for abuse.
Also, correctly caching your API responses means that, no matter how many users your website has, you will always be making roughly the same number of requests, again avoiding hitting the rate limit if your website suddenly becomes very popular. Fortunately the TfL API is free to use, but if you apply the practice of using APIs directly from a website without a backend server on other (paid) API services, this could very easily spike your costs.
If you don’t have the resources or the technical know-how to run your own full-blown backend server, there are many services such as Netlify, Vercel, and Cloudflare; which allow you to create “serverless functions” (many with free or discounted plans available), which you may use to act as “wrappers” for your API calls, so that your keys remain private.
I have a recollection of reading that the Unified API provides a SignalR hub to push predictions following a single request. Is that something the OP should use to avoid requesting each line status every 8 seconds? Presumably it would still require a unique key for each instance of their programme.
That’s all very good guys but I’m programming this in C# (which has already been written to parse XML files) not Html or Javascript etc.
Plus that bit of code is only dealing with 1 station (Old Street?)
As for the every 8 seconds, if we consider that i am requesting 10 files (1 for each line) in that time (of course it would be better if all those lines could be in 1 file which would then equate to 1 request? but that’s not available) this equates to 80 requests a minute, which for me using my key in the app has been fine.
So if i get my users to subscribe for there own key that they can put into the program (in place of mine) then they should also be fine?
After all it does say this where you subscribe…
Anonymous access to our API is limited to 50 requests a minute. If you want to call the API more than that, you’ll need to subscribe to a “Product” which lets you bypass this limit with a subscription-key that you append to your requests.
This brief discussion set me thinking about the pros and cons of push versus pull from the perspective of server load. There was some research on this using various public servers including TfL’s. They concluded that where the maximum acceptable latency (MAL) on the client is above 10 seconds, then polling is the preferred interface based on the number of clients that can be served. As far as I can see from the JS-Fiddle example, TfL predictions are normally refreshed more slowly than 10 seconds.
It would be interesting to hear from @LeonByford or @jamesevans whether TfL have ever considered this and how much use is actually made of the push API.
The push API is perhaps most useful for bus predictions, as we are able to stream them from the Countdown system. I think for all other modes, we poll for data, so latency will be introduced even if you use our push API.
In the future we aim to reduce latency, and this would hopefully increase the benefit of using a publish-subscribe mechanism to access our data.
Are there any plan to introduce a Unified API which can let me subscribe to live times for all TfL modes matching the journey planner timetables (except Overground and Elizabeth line, which are National Rail services)?
Hi, the SignalR push API should allow you to subscribe to live predictions for buses, Tube, DLR, trams and River Bus.
We are aware, however, that it is not straightforward to cross-reference the live data with the published timetable data, and are actively working on measures to address this.
I understand from your previous messages that you would like SIRI-ET or GTFS-RT feeds. This is useful feedback that we are taking on board; we would encourage open data users to let us know what they would like us to offer.
I mentioned in another thread that the Traveline Nextbuses API already does that for all bus services where live arrivals are available - except TfL where it provides only scheduled times. Do you know whether that is a decision by Traveline or TFL, or is there a reason why it is more difficult with TfL services?
That’s a great question. We had some discussions about this earlier in the year, but I’m not sure where that ended up. I’ll check in with my colleagues who were looking into this.
