Changes to Trip Planner API's

Status Updates
1

What is happening?

The trip planning engine will be upgraded to a new version, which introduces several changes to the Trip Planner API. This upgrade ensures that trip planning engine continues to receive new features in the future.

When is this happening?

Pending internal confirmation, the update is scheduled for Wednesday 27 August 2025.

What does this mean for me?

There will be no outage or disrupted access to data from the APIs.

We have implemented backward compatibility mapping for all updated attributes to ensure a smooth transition. Therefore, no or minimal changes should be required on your side. Once the update is made, users will see the following:

General Changes:

  • New response attributes added – These are placeholder attributes that may not be present in future releases and should not be used.

  • Locality ID update – The value of the locality id has changed.

  • Updated API response – All API responses are now using rapidJSON version 10.6.21.17.

API-Specific Changes:

  • /coord endpoint – The locations.id field for stops has been replaced with the child stop ID.

How can I get further support?

Please contact our support team at opendataprogram@transport.nsw.gov.au if you have any questions.

1 Like
2

:mega: Please be advised that this change was successfully completed. :tada:

3

Actually, part of the problem is that the documentation provided here for the Stop Planner API is still referring to version 10.2.1.42, however the latest release is 10.6.21.17. How do we view the documentation for the latest release?

Finally, I am specifying the version parameter in my queries to try and protect myself against breaking changes like this, however it seems as of this update, the API ignores the version parameter and it always returns version 10.6.21.17.

4

Hello

Despite your assurances that this update is backwards compatible, I am finding that it is not backwards compatible and I suddenly am no longer receiving any stop results from the stop_finder API, with my previously working queries.

Specifically, if I call it with type_sf=stop and name_sf=Central, then I get an error, when this used to be perfectly valid:

{
  "type": "error",
  "module": "BROKER",
  "code": -2000,
  "text": "stop invalid"
}

The documentation says

To lookup a stop set type_sf to stop and enter the stop id or global stop ID. For example, 10101100

However, I used to be able to search stops only by name, not just by ID.

If I don’t provide the type_sf parameter at all, then I get no results, even though this parameter is supposed to be optional. I must specify type_sf=any to get any results at all.

I was only able to figure this out by examining the requests made by the Trip Planner at https://transportnsw.info/trip

I notice that they send type_sf=any, but then also specify this special undocumented parameter TfNSWSFStopsOnly in order to specify whether to get stops only, which should be controlled by the type_sf parameter instead.

If the API has indeed changed, then this should be announced as a breaking change and be properly documented.

5

Thank you for raising @samleatherdale. I will review the documentation and swagger information on our Trip Planner API dataset page.

6

Hi Steven, thank you for your message.

Yes the Trip Planner API has been through an upgrade as there has been changes in the back end- see here.

We have had similar feedback and have sent this back to the team. They are awaiting feedback from their vendor.

I will respond when we get an answer.

Thanks, Marcela