Extra Bus Workings Discrepancies

I’ve noticed that in the Bus, Coach and River instant API feed bus services working as school extras (due to Covid) there are some routes with a ‘V’ prefix (e.g. V162). But in the Unified API these routes and workings do not exist. Why is this?

Instant API - Depending on the time of day, this may not work:

Unified API:

According to the Countdown feed documentation…
“LineID” “The identifier of a route. This is an internal identifier and is not equal to the route number displayed on the front of the bus / river bus. It should not be displayed to the public.”
LineName = "This is the route number that is displayed on the front of the bus / river bus and on any publicity advertising the route. "

LineID “V162” is the internal identifier and LineName for these same entries should show “162” which is what should be displayed on the buses. If you look at vehicles working the V routes in the Countdown feed, do you see the same vehicle registration numbers in the unified feed but working route 162?


1 Like

Ah yes, I do actually. Thanks for this. I think I’ve just been mapping the data incorrectly

Now onto the next discrepancy…

Right now I see a London Overground replacement bus appearing in the instant feed: http://countdown.api.tfl.gov.uk/interfaces/ura/instant_V1?ReturnList=RegistrationNumber,LineID,LineName,StopPointName,StopPointIndicator,DestinationName,EstimatedTime,StopCode2&LineId=UL7

Now using one example on here, where the vehicle registration of the bus is SN59AWO and the LineName is LO-T:

    "Walthamstow Bus Station",

If I try to look for the ETAs for this vehicle, the results are empty: https://api.tfl.gov.uk/Vehicle/SN59AWO/Arrivals


Why is this?


As I recall (I wrote an app for MTR Crossrail, as was) iBus isn’t programmed to make predictions about replacement bus services. I recall the exact reason, but it’s possibly that it’s a combination of infrequency used routes, limited stop services or lack of funding to input the routes into the system.

iBus isn’t an AI, as you might expect, the code is hard-wired by “timetable people”.

Also, scheduled RRBS services for National Rail services also end up in NRE Darwin, so the likes of Google Maps can see them.

Ah, I see. Thank you for this insight.

It’s interesting as I see drivers are still able to log into a rail replacement service so passengers can see what route their on and the upcoming bus stops (as with normal bus services). Some bus stops with eta screens also show rail replacement services due at a bus stop. You’d think these would use or contribute to the open data feed but I guess not.

1 Like

I’m quite sure that RRBS never appear on the Countdown signs. That was the heart of the problem.


ETAs are available for TfL Rail Replacement Services - as I type this at 22:25 on Sunday 29th November, there is route UL-24 running. LVF is showing predictions for Abellio 2424 (and others) currently on the route.


Countdown won’t provide an ETA, IIRC, if the vehicle is turned off i.e. on a stand between journeys or if the vehicle’s next stop is beyond the 30 minute window that Countdown works in which may be what affected @nathanodong’s original query - That vehicle appears to be at Walthamstow heading for Barking, could it be, for example, that it was due to leave Walthamstow in 29 minutes and therefore the next stop after Walthamstow was beyond that 30 minute limit. It seems here that the Countdown API did provide an ETA but the Unified API didn’t, that one I can’t explain!

@nathanodong, Why do the first query in the Countdown API and then switch to the Unified one?


Apologies, I didn’t see this reply.

RRS does indeed appear on the countdown signs. I personally saw the London Overground replacement service appear at a stop near Gospel Oak a few weeks ago. So ETAs must be coming from some feed somewhere (probably the Countdown API rather than the Unified API as @SJCooper mentioned.

I don’t see the point of querying the Countdown API for ETAs, then use the Unified API for everything else. I’d rather do one request than two. In my view, the Unified API should be providing everything as suggested in the name.

I haven’t checked, but do RRS buses appear in the ETAs at tube/train stations in the API rather than bus stops? Maybe I’ve been looking in the wrong place.

They are shown at the bus stops themselves in the screen grab posted above.

If the buses do appear on relevant Countdown screens, do they show the route “UL24”? The buses themselves usually show “A”. “B” or similar on a clipboard in the front of the bus when I have seen them. I have a feeling that “UL24” is meant to be an internal TfL designation but it has clearly escaped into the public domain; I’ve seen it on Google maps info about bus stops. Seems to me it would be sensible to display the same route number everywhere, particularly when (as some do) the service runs for several weekends rather than one.



The “UL24” type designations are in the https://tfl.gov.uk/tfl/syndication/feeds/bus-sequences.csv file which is technically in the public domain.

However, usually the routes are labeled, as you say, with letter when you see the notices in tube stations when there’s a closed notice. Confusingly they usually use a the first letter of the line that’s closed which can clash (DLR/District, Central/Circle) and there are already services starting with “D” too.

I think the Countdown (back-end) system feeds into both the legacy and unified APIs.

The reason I was asking why you were using both APIs is that you’ve quoted both…

Legacy (Countdown API)


Unified API

So, which are you using?


I’ve changed my application to only use the Unified API now. I used to use the Legacy feed to get a snapshot of all vehicles in service, but the extra processing I had to do was slow and complicated. I tried to do this via the Unified API but kept receiving errors. Since the dev portal opened back up again it has seemingly gotten better :man_shrugging:t6:


If you want a feed of data to use, use the Legacy system as you can leave the call open 24/7 and consume the whole data feed. It’s simple httpd digest so it’s very easy to code up if you want everything when it happens.

If you want one-off data to display in direct response to a user input, use the Unified API.

It is possible to to use the Unified API as a streaming input to consume the whole feed, but you have to be using .NET SingalR. Scroll down to “Time on my side” in

I’ve tried using the stream in the Unified API for my Java application, but the available library is incompatible with the version of SignalR they are using (to be fair, this is the fault of Microsoft not providing a proper Java client). And as far as I know you can only use it to stream ETAs for 1 bus stop only, which didn’t meet my use case.

I used to use the legacy instant service because I wasn’t given access to the stream (the Countdown team never replied to my last email explaining why I wanted access). I stopped using this because the Unified API got better, and the legacy responses aren’t in valid JSON format so extra string manipulation was required making things more complicated.

In one of the emails they sent to me, they implied that they’d prefer developers use the Unified API as opposed to anything else. This has been further emphasised with the changes on the dev portal where they have pretty much hidden the legacy feed information from sight. The API is great, but it seemingly doesn’t have all the functionality that would be useful for me. That’s the trade off I guess…


I had a go at writing my own SignalR client in PHP, and I gave up when I found the malformed JSON!

There’s also code on the Microsoft site to do it in Javascript - https://docs.microsoft.com/en-us/aspnet/core/signalr/javascript-client?view=aspnetcore-5.0 - but again I didn’t readily work.

The whole of the TfL API system is covered with endless .net redundancy which makes the calls larger than necessary (many times over)

and I can only assume is because Microsoft got it’s tentacles into TfL as they have want to do.

It’s a shame that SignalR is the only option and it has very poor non-Microsoft .net support