Difference between StopPoint arrivals and TrackerNet


I am new to this forum but I have recently been trying to use the api StopPoint/{id}/Arrivals to get a list of the next tube/overground arrivals at a given station but my responses seem to be slightly different from the ones that I find on the tfl website. I have seen people reference TrackerNet but I’m not quite sure what the difference is between this and the StopPoint arrivals.

If anyone has any advice on what method would be best for me to use to get a live arrival board for one station that would be great :).


Welcome @isaaccornford

TrackerNet is the system “behind” the unified API and generally speaking should be used in preference for new code. As far as I know all of the data on Trackernet is now showing in the Unified API calls.

Given that you need to know lots of out-of-date things to get Tracketnet to work, such as the unique set of station codes, it is unlikely to be of benefit.

Of course NEITHER of these systems is able to show the correct data for ****ing departures from terminal stations because the API is showing arrivals NOT departures. So no useful data for your Edgwares, High Barnets, your Mordens, Eppings, Hainaults, Upminsters, Richmonds, Wimbledons, Ealing Broadways, pink Hammersmiths, silver Stratfords, Brixtons, Walthamstow Centrals, pink Barkings, green Edgware Roads, or your Elephants, Castles, Harrows & Wealdtones, nor purple Aldgate, Amersham, Chesham, Watford and any colour Uxbridge. And Cockfosters and Heathrows.

If you want to scan the whole tube network, it’s quicker and easier to use the line-based endpoints.


and then


(if you want a list active line codes, https://api.tfl.gov.uk/line/mode/tube,overground,dlr,tflrail,tram/status is very fast)

Thank you @briantist that’s a very helpful explanation.

Would you recommend searching all the lines that relate to the station and then check to see what trains are passing that station from there? I had considered this but wasn’t sure if it would be too inefficient for my code or if it was unhelpful to request data from more APIs than necessary.


As I’m writing a web-app where the server is shared between many users, I have taken the scan-lines-and-filter approach because I can limit the number of calls to the TfL API to 15 per minute (as they get memcache), rather than having to calls on a per-station basis.

With the TfL APIs it is generally quicker to call less and then filter more because they can be cached by the whole user-base and therefore return quickly.

The calls, by speed would be

down to

It’s worth remembering that you are rate-limited to “500 requests a minute.” which is easily reached if you have lots of clients.