# Tour endpoint returns repeated and missing stops **URL:** \ **Category:** API\ **Created:** [November 10, 2026, 11:14am UTC](https://support.routexl.com/t/tour-endpoint-returns-repeated-and-missing-stops/3305 "2026-11-10T11:14:04Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![gesuga](https://support.routexl.com/letter_avatar_proxy/v4/letter/g/df788c/32.png) [@gesuga](https://support.routexl.com/u/gesuga)\ **Post date:** [November 10, 2026, 11:14am UTC](https://support.routexl.com/t/tour-endpoint-returns-repeated-and-missing-stops/3305/1 "2026-11-10T11:14:04Z")
Hello, We use RouteXL to optimise truck routes through the tour endpoint (parameters: type=smalltruck, speed=100, directions=true; no skipOptimisation). Since 1 November, and much more often today (10 November), some optimisation responses come back with feasible=true and the correct count, but the route is wrong: one stop is repeated several times and other stops are missing. All coordinates we send are distinct. It happens on several different routes. Example from 10 November, a route with 10 locations: one stop came back 5 times and 3 stops were missing. Response ids with this problem: 4A7wGMy14g8dH56AJrqw, CDR9GK6k1IL425OhvEt4, IGAjqdodnN462s10Q8wF, 7Sc81V8JwHN61HzhTVOd, da18wj6K6U9HV7b9vKvf, Mnpgz76L7FMxiAqQylkF The identical request returned a correct route at 08:30 (VmmF3zS5S68PuR6T9I6s) and a wrong one at 08:26 and 08:38. We reproduced it outside our application by sending that same request 50 times, one at a time: 40 responses were wrong, always with the same stops missing, in streaks of bad and good responses. Could you check this and tell us if it is a known issue? We can send the full request and a wrong response if needed. Thank you, GESUGA ---
**Author:** ![RouteXL](https://support.routexl.com/user_avatar/support.routexl.com/routexl/32/347_2.png) [@RouteXL](https://support.routexl.com/u/RouteXL)\ **Post date:** [November 10, 2026, 12:02pm UTC](https://support.routexl.com/t/tour-endpoint-returns-repeated-and-missing-stops/3305/2 "2026-11-10T12:02:33Z")
We’ve seen a similar issue, it may be related to a system upgrade we were [forced](https://support.routexl.com/t/service-interruption-due-to-critical-vulnerability-php-solved/3303) to implement. If you can share your request and the result, we’ll check in more detail. If you do not want to share your data here, feel free to email us directly at [info@routexl.com](mailto:info@routexl.com) ---
**Author:** ![Initeam](https://support.routexl.com/letter_avatar_proxy/v4/letter/i/858c86/32.png) [@Initeam](https://support.routexl.com/u/Initeam)\ **Post date:** [November 10, 2026, 12:43pm UTC](https://support.routexl.com/t/tour-endpoint-returns-repeated-and-missing-stops/3305/3 "2026-11-10T12:43:13Z")
We are seeing the same problem since this morning (10 November) on POST /tour, API v2, with skipOptimisation = 0, type = smalltruck and speed = 100. The response has status 200, feasible = true and the correct count, but one location is returned several times and other locations are missing. All locations in our requests have a unique name and distinct coordinates. Figures from our logs: - 2 to 9 November: 235 optimisation requests, none with a repeated location - 10 November: 34 out of 44, the first at 10:20 and the most recent at 11:37 (CET) - Requests with skipOptimisation = 1 come back correctly - An identical request gave a wrong route at 10:28:13 (response id CueBG226n230qXL4E13w) and a correct one 13 seconds later (ZyEJB9N7Udzd2e6P7kQ0) Other affected response ids: xRoT2wls7TlK5Mc12DD0, BDeJ9j5G080qE684hn7b, nVo9AmWeMYyorg3r0Y77. We have sent the full requests and responses to [info@routexl.com](mailto:info@routexl.com), because they contain customer addresses. Is there any news on the cause or on when a fix can be expected? ---
**Author:** ![RouteXL](https://support.routexl.com/user_avatar/support.routexl.com/routexl/32/347_2.png) [@RouteXL](https://support.routexl.com/u/RouteXL)\ **Post date:** [November 10, 2026, 1:00pm UTC](https://support.routexl.com/t/tour-endpoint-returns-repeated-and-missing-stops/3305/4 "2026-11-10T13:00:45Z")
The problem seems to be one of our dedicated servers where the algorithm runs. We’ve taken that specific system out of production, which seems to solve the problem client-side. We’ve also added an additional check on the other servers. We’ve not yet finally determined the cause but it seems a configuration and/or hardware issue. We’ll continue to work on that, to solve the problem and prevent it from happening again in future. [Edit: updated with latest status]