Run the full crew booking lifecycle, one step at a time, against the sandbox — with the real request & response shown at each step.
client_id / client_secret it gives you. Paste them below.
200/202.
Whether it actually books depends on configuration that is approved
outside this page, so on a company where that has not been done you will see
the work land as a review item rather than a booking. That is the API behaving
correctly, not an error.
NEEDS_REVIEW saying the station has no hotel config, even
though step 3 just set one. Switching a contract on is a reviewed action,
so it has to exist and be approved before the schedule is
submitted.NEW_DEADHEAD is returned as
PENDING_REVIEW with a flight_options_url, and
you pick and commit the flight yourself. That is what steps 6–8 below do,
so the walkthrough works either way.POST /crew/config/hotels/{hotel_config_id}/contracts, then
PUT …/contracts/{contract_id}/rates covering the contract's
full date range, then POST …/hotels/{hotel_config_id}/change-requests
with intent: ENABLE. Approving that request is an agent action and is
deliberately not on this API — so on a company that has never been set up, a first
run stops at the review step by design rather than booking the hotel. Ask your
Routespring contact to approve it, and to switch on deadhead auto-booking if you
want that too. The full list is in the
API reference.
Nothing is stored or sent anywhere except directly from your browser to the sandbox endpoints above.