Hi All,
Myself and a small team of trainee developers are trying to make an app focused on data sonification of tube arrival times for a number of main lines. The idea being, when a train arrives, a tone is triggered…there is a lot more to it but I don’t want to bore you! We are using a javascript/express/node.js stack and I am making fetch requests with no issues to the unified api, specifically to this end point: https://api.tfl.gov.uk/Line/:line/Arrivals. Problem is, every time we make a request, the data seems to flick between up to date and old (based on the timestamp) and there doesn’t seem to be any reliable way to ascertain where a train is or when it has reached the platform. Even the ‘at platform’ value seems a bit unreliable. I have seen interactive maps and trackers that appear to use this unified api. So my question is, what could I be doing wrong? Is there a better way to get regular up to date arrival information for trains along a line?
Thanks in advance 
@abodian Wecome.
Are you using your app_key when making the requests? I think this behaviour can be seen if you fail to use your app_key.
Thanks for the reply Brian. Yes app_key and id both in there for the requests.
Hi @abodian, can you please try again? We’ve reset our API cache just now which should hopefully resolve the issue
Hello, still seems to jump around a lot. I’ve shown an example in this video:
You can see on lines 16 and 17 of the postman console that the timestamp and seconds to arrival are jumping up and down and alternating between older timestamps and new timestamps. Unless I’m misinterpreting things.
The link expires after a day.
I have the similar issue
Sometimes expectedArrival changes to the old date.
Today I got 2023-02-27 several times in the response
Im not sure this is doable as what TfL provide are predictions, so it may or may not always align with when the train actually arrives.
i feel like this kind of app would require a entirely different API to what TFL provide us i.e. some type of implementation like websockets or even webRTC (though this probs wouldn’t scale) and GPS on every TfL vehicle this is doable in theory i’m not entirely sure if TfL desire to do this in practice
its a cool idea though its just my experience of the API and mapping it on to reality tell me although , you’d be better off signalling to your users when the train is 1 minute away (but understand in reality it might not be as it could be delayed for a myriad of reasons).
The predictions loosely showcase what is going on for example, the buses with vehicle registration nos turn up sometimes well after the “expectedArrival” sometimes not at all ,sometimes before sometimes there are buses that arrive that have vehicle reg nos that are not present in the data for the entire day (i have checked, lol)
i’m sure there are perfectly plausible reasons for the above and as i am writing this i could think of some , but from my experience with the API i would say your app would be impossible to build with the API that TfL currently provide, you should tweak your expectation for now to nowish lol to put crudely or from "your train as arrived " to "due ".
“Due” is what most consumers of TfL in all honesty are used to anyway that or delayed by n minute(s) lol.