Verticals
Travel
Provider-specific behavior for the travel vertical. Hotels and Flights differ from each other more than either differs from dining — see the page for the provider you are calling.
"vertical": "travel"Hotels and Flights
termA city, neighborhood, or hotel name, e.g. "downtown Chicago", "The Langham".lifecycleSearch takes check_in and check_out instead of dining's single datetime, plus rooms (how many rooms to book; defaults to 1); party_size is total guests across all rooms (defaults to 2). Hotels has no OTP step, and nothing is placed until you confirm. Book without a card and the booking returns requires_action with next_action.type "payment"; submit the card to POST /v1/bookings/{id}/continue (card_number, exp_month, exp_year, cvv, postal_code, name_on_card). That fills the card in and returns requires_action again with next_action.type "confirm"; send {"confirm": true} to /continue to place the reservation, which charges the card. Adding "confirm": true to the card body skips that round, and a card sent up front in metadata.payment on POST /v1/bookings skips both rounds: the order is placed in that call, unless metadata.confirm is false, which stops at the confirm round. See the Hotels page for the full walkthrough. Flights is the same four endpoints with a different spine: the venue is a route rather than a place, itineraries are addressed by a stable itinerary_key rather than an availability_id, travellers[] carries one block per seat, and POST /v1/bookings only drives the checkout and parks — the irreversible press is confirm: true on /continue. See the Flights page.