Retrieve the StopPoint id using common name


I am trying to retrieve the StopPoint id of a station given the common name, but the id returned by the StopPoint/Search endpoint seems to be wrong.

Here is an example searching for Farringdon:

Here is the response:

  "$type": "Tfl.Api.Presentation.Entities.SearchResponse, Tfl.Api.Presentation.Entities",
  "query": "farringdon",
  "total": 1,
  "matches": [
        "$type": "Tfl.Api.Presentation.Entities.MatchedStop, Tfl.Api.Presentation.Entities",
        "icsId": "1000080",
        "modes": [
        "zone": "1",
        "id": "HUBZFD",
        "name": "Farringdon",
        "lat": 51.520214,
        "lon": -0.105054

The id HUBZFD seems wrong to me and if I try to use this id with the StopPoint/:id/Arrival endpoint, I get no results.

Meanwhile, if I look for the id of Farringdon station using a different endpoint (i.e. the Line api), I get 940GZZLUHSC, and this id works perfectly with StopPoint/:id/Arrival,

Now, can you explain why the StopPoint/Search is returning the wrong id?


Hi @pasine
That’s a hub ID which is an amalgamation of nearby StopPoints that make up a transport hub. We created these for our own products. So for Farringdon that will include tube and National Rail plus likely closest bus stops. Here’s a handy blog post to explain how to search for Stop IDs. It also explains what a hub is. Let me know if it helps answer your question.



You know that there is a hub there but most potential users presumably do not, so have no idea whether what they will get back from a simple name search will be a hub or a stop. Perhaps there is a method by which the user can specify which they would get if both exist?

In some circumstances a complete list of departures from every component of a hub could be very useful but I take it from the original posting that nothing is generated.

As an aside, if I search for “Farringdon Station” on journey planner and I do not actively select the single entry underneath with a tube symbol next to it, I am told that more than one matching location has been found - but only one option is shown! If I search for Farringdon on its own I get a list of options, which is fair enough.

The geographical hierarchy may be perfectly clear to those who set it up but from the outside it seems like a little imp is in there trying to make it more difficult than you would (perhaps naively) hope.


@mjarchive We are very much aware of the limitations of our open data products. The Unified API was built primarily to power our website and the needs of third party developers were not at the forefront when designing it. We’ve learned from that and aim to bring in feedback from third party users when designing any new data products. Tackling the tech debt of the existing products is also on our wishlist but, with limited resources, subject to other priorities. Our Tech Team wrote the API blog posts to try to mitigate some of the quirkiness in the API, including this anomaly. I’ve raised a ticket for this (SVC-6072) to be considered as a future enhancement so it’s in our backlog and hopefully sorted out properly at some point. I’ll pass the JP issue on to the relevant product manager to take a look at.


@theochapple thanks for your article. I must admit the system is not really straightforward.
So, assuming I want to know all the arrivals at Farringdon Tube Station, I would have to

  1. Make a request using StopPoint/Search using the common name (i.e. Farringdon)
  2. Retrieve the ID, without knowing if it’s a hub Id or a platform id
  3. Make a second request to StopPoint/:id (i.e. HUBZFD)
  4. Loop through the results to find a match for the mode I am interested in (i.e. tube) or naptam type? (i.e. NaptanMetroPlatform)
  5. Retrieve the ID of the platform (i.e. 940GZZLUFCN is the first id I get if I look for NaptanMetroPlatform)
  6. Make a third request to StopPoint/:id/Arrivals to get the results

Is this the right procedure or there is a better one?


Theo - Thanks. I fully understand that a lot of Open Data comes from applications which preceded the goivernment’s open data initiative best part of ten years ago. I can distinctly recall the Big Announcement at the time, followed almost the next day by being hassled by the progenitors because our data were not immediately available in machine readable form!

I also know from experience that there are lots of questions to which the answer is obvious - but only once you know it. That can lead sometimes to those who know not appreciating how impenetrable it can seem to those who don’t.

I’ve never been convinced that the hierarchy/approach in Journey Planner really fits passengers’ needs but that, while a bit related, is part of a different story. In planning I don’t usually care much which stop/platform a bus/train leaves from but in presenting Countdown data on describers separating them out is paramount. I think that gives rise to some of the tensions that I see.