The endpoints for adding, reordering and removing stops1 now sit with the record they
edit: under /api/bookings for bookings2 and under /api/tours for tours3,
next to the other booking and tour endpoints. Each endpoint now documents the permissions for its own
record type, so its documentation says exactly which roles may call it, and in which states.
The new paths
| Endpoint | Path |
|---|---|
| Insert custom stop into existing booking4 | POST /api/bookings/{booking_id}/stops |
| Order booking’s stops5 | PUT /api/bookings/{booking_id}/stops/order |
| Remove stops from a booking6 | PUT /api/bookings/{booking_id}/stops/remove |
| Insert custom stop into existing tour7 | POST /api/tours/{tour_id}/stops |
| Dispatch or move stops into existing tour8 | POST /api/tours/{tour_id}/stops/insert |
| Order stops of a given tour9 | PUT /api/tours/{tour_id}/stops/order |
| Remove stops from a tour10 | PUT /api/tours/{tour_id}/stops/remove |
| Deduplicate stops of a tour11 | POST /api/tours/{tour_id}/stops/deduplicate |
Requests and responses stay the same; only the paths change.
The earlier paths keep working
Every endpoint is still reachable at its earlier path, which starts with /api/hailing/ instead of
/api/, for example /api/hailing/tours/{tour_id}/stops/order. Nothing needs to change in your
integration right now. We will deprecate the earlier paths at a later point and announce it here with
a deadline, well ahead of time. Until then, please use the new paths for anything you build or change.
One record type per endpoint
The booking endpoints only accept bookings2, and the tour endpoints only
tours3. A tour id on a booking endpoint, or a booking id on a tour endpoint, returns
404 Not Found, at the new paths as well as the earlier ones. To edit the stops1 of a
tour, use the tour endpoints from the table above.