Every crew workflow, one contract.

Returns a paginated list of schedule submissions for your airline, ordered by submission time descending (most recent first). Use this to look up a scheduleid when you don't have it from the original submit response, or to audit submission history. No filter is required — omitting all parameters returns the most recent 50 submissions.

Push the airline's roster to Routespring as a JSON payload. Each submission represents the complete current state of all open pairings — Routespring computes the diff against the prior submission server-side and derives action items accordingly. Returns 202 immediately with a scheduleid; diffing, classification, and booking run asynchronously. Track outcomes at the three async levels described in the Async outcome model section of the API overview. Briefly: a submission of 200 duty periods where 3 individual hotel bookings fail surfaces as ProcessingStatus: COMPLETED plus 197 CONFIRMED and 3 FAILED bookings, each retrievable individually. JSON is the only ingestion format: the airline-workflow anchors (pairingnumber, employeeid, …) flow through as structured fields tied to your operational vocabulary.

Returns the full metadata and processing summary for a single schedule submission. Use this to check the outcome of a submission — how action items were distributed across auto-booked, pending review, and failed.

Returns the action items Routespring derived from this schedule submission. Each item represents one booking decision — what the engine determined needed to happen and whether it acted automatically or held it for review. Call this after polling processing-status until pollrecommended is false. Filter by disposition: PENDINGREVIEW to find items requiring human action, or by type: FLIGHT to see all deadhead positioning needs.

Flat CSV of every action item from this schedule submission. One row per action. Machine-readable; suitable for ingestion into airline-side BI / analytics systems.

The airline already knows what booking is required and asks Routespring to run it through the booking engine — searching the supplier pool, applying the active configuration, and either auto-booking or flagging for review per the same rules that govern diff-derived action items. Primary use case — IROPs. When operations diverges from the published roster (weather diversion, sick crew, cascading delay), the airline computes the new booking requirement before your crew management system catches up. Calling this endpoint with source: IROP and an iropref correlates every action item, booking, and audit event for that IROP for after-action analysis. When to use vs alternatives: Diff-derived (normal flow): just POST /schedules. Routespring computes the action items. Airline has not selected a specific flight, wants Routespring to search + auto-book per config: this endpoint. Airline has selected a specific flight (via GET /flight-options) and wants to commit it: POST /bookings/request instead — that path skips the search step and goes straight to the supplier. Returns the created ActionItem immediately (202). Execution (v1). Both HOTEL and FLIGHT injections are auto-booked asynchronously through the same engine the schedule flow uses (supplier search + selection + rate/fare from config); poll GET /bookings/{bookingid}/status for the outcome. POST /action-items takes no flightoptionid — the engine searches and selects the positioning flight for you. (If you have already chosen a specific flight via GET /flight-options and want to commit that exact one, use POST /bookings/request instead.) Resulting Booking.manualoverride defaults to true so a subsequent schedule submission's diff engine does not revert the injected booking. Idempotency (optional). Send an Idempotency-Key header to make retries safe: a repeated key for the same airline replays the original action item instead of injecting (and booking) a second time.

Returns your airline's active hotel configuration — the preferred hotel per crew base, with its contract rate and check-in/out policy. The booking engine uses the hotel configured for the crew member's layover city, matching against the contracted rate. To retrieve a historical snapshot, use GET /crew/config/hotels/versions/{version}.

Replaces your airline's hotel configuration. The full list of bases and hotels must be sent — this is a full replacement, not a merge. One hotel per base. The previous config is archived as an immutable version; every booking records the config version active at the time it was made. The booking channel is derived from each propertyid: a match in Routespring's GDS inventory (look it up via GET /hotels) books via GDS; a propertyid that is not in the inventory is a DIRECT hotel only when it supplies its own chain. A non-inventory propertyid with no chain is treated as a mistyped GDS id and rejected with 422 UNKNOWNHOTELPROPERTY. handlertype is therefore not sent on input — it is returned (derived) on the config response.

Returns your airline's carrier and cabin preferences for deadhead positioning flights. The booking engine applies these when searching for and selecting flights on behalf of crew.

Sets your airline's carrier and cabin preferences for deadhead positioning flights. Blacklisted carriers are never booked. Preferred carriers are tried first; if none have availability, the engine considers any non-blacklisted option. Set samecarrierpreference: true to prioritize your own airline's flights when repositioning crew.

Returns the price ceiling for auto-booking positioning (deadhead) flights. If a booking lands in NEEDSREVIEW unexpectedly, check autobookmaxprice — fares above this amount are held for travel manager approval rather than booked automatically.

autobookmaxprice is the per-ticket ceiling for auto-booking a positioning (deadhead) flight — fares above this are held as NEEDSREVIEW for travel manager approval rather than booked automatically. Only fields included in the request are updated; omitted fields retain their current values.

Returns your airline's automation settings — the flags that control what Routespring executes automatically versus holds for human review, the account under which engine-driven bookings are placed, and the rate matching mode that determines how strictly contracted rates are enforced at booking time. When an automation flag is disabled, Routespring creates an action item for your team to handle instead of executing automatically. See the Action Items section for how these are surfaced and managed. If bookings are landing in NEEDSREVIEW unexpectedly, or automated cancellations and modifications are not executing, check these settings first.

Sets the crew booker account and the booking preferences exposed here. crewbookeremail is required — all engine-driven bookings (hotel layovers, diff-engine amendments and cancellations) are placed under this account. Manual flight commits via POST /bookings/request are booked under the bearer token making the call. Omit a field to keep its current value. The automation execution levers (cancellation / modification / swap / deadhead-flight execution, NOC stats) are Routespring-managed and not set through this API.

Returns the immutable snapshot of the named config at the given version. Use this when a booking's configversionused references a non-current version and you need to know exactly which rules applied. The response shape depends on configtype: hotels returns a HotelConfig, flights returns a FlightConfig, etc. Note: only version = v1 resolves; any other version returns 404.

Bookings are denormalized with all anchor keys, so any combination of the query parameters below returns the same booking record set. At least one filter is required.

Returns paginated flight options for a given origin/destination/date. Use this when you want to manually select a specific flight rather than letting Routespring auto-book via its built-in logic. Default behavior (no call needed): Routespring auto-selects and books the best available flight based on your booking configuration (preferred airlines, cabin, autobookmaxprice, etc.). You only need this endpoint if you want a human to review and pick. Typical IROP flow: 1. Call this endpoint to fetch options (10 per page by default). 2. Present pages to the travel manager. 3. POST the chosen flightoptionid to PATCH /bookings/{bookingid} or to POST /bookings/request to lock in that specific flight. Results are sourced from the same supplier pool Routespring uses for auto-booking. Prices and availability are live at query time.

"I've already decided what to book — just book it." Pairs with GET /flight-options: airline searches, picks an option, posts the flightoptionid here. Execution (v1). A HOTEL request is booked for real, asynchronously, through the same engine the schedule flow uses (duplicate check → supplier selection in priority order → rate from config). The call returns 202; poll GET /bookings/{bookingid}/status for the outcome. A FLIGHT commit that carries a flightoptionid is booked for real through Routespring's internal Flights API — it tickets and yields a PNR, ticket number, and trip-session id; poll GET /bookings/{bookingid}/status, then read those off the flight block via GET /bookings/{bookingid}. A FLIGHT commit that omits flightoptionid and instead carries a route + date (fromairport + toairport + departdate) auto-selects and books the best matching flight — the same way a hotel commit auto-selects when propertyid is omitted (see BookingRequestFlight). (Deadhead positioning flights derived from POST /schedules are booked automatically by the engine and don't need this call at all.) When to use vs alternatives: The airline wants Routespring to search + auto-book against its config: use POST /action-items instead. The booking already exists and needs to change: use PATCH /bookings/{bookingid}. Diff-derived (normal flow): just POST /schedules. Typical IROP flow end-to-end: 1. Detect IROP in airline ops system. 2. GET /flight-options?fromairport=EWR&toairport=SLC&arriveby=...&employeeid=... 3. Travel manager picks an option (or your automation does). 4. POST that flightoptionid here with the anchors and a classification (IROPNEWDEADHEAD, IROPREROUTE, …). Bookings created here default to manualoverride: true so the eventual catch-up schedule submission's diff engine does not revert this booking. Set manualoverride: false to release immediately to auto-management. Idempotency (optional). Send an Idempotency-Key header to make retries safe: a repeated key for the same airline returns the booking the first call created instead of committing a second time. For HOTEL bookings (where there is no flight-options analogue), the airline supplies the city + checkindate + checkoutdate plus an optional propertyid to pin a specific hotel from its preferred-hotels config. If propertyid is omitted Routespring auto-selects per priority order — useful for hotel IROPs where the airline just needs any preferred hotel locked in fast.

Modify an existing booking. Routespring performs the supplier change and returns 202 with the booking record reflecting the outcome (MODIFIED on a successful amend, or NEEDSREVIEW if the supplier rejected it). How the change is applied. A hotel date-window change (check-in / check-out) is applied as a true in-place supplier amend — the bookingid and supplier confirmation are preserved and the booking ends in MODIFIED. A hotel property swap or any flight change is applied as a cancel-and-rebook: the original booking moves to CANCELLED and a new CONFIRMED booking is created. Company levers (Routespring-managed, not set via this API in v1). An explicit PATCH always performs the requested amend — it is a deliberate operator action and is not gated by the per-company booking-modification execution lever (that lever governs only the automatic schedule-diff path). The strict-price-match lever still controls how strictly the amended rate must match the contracted rate (a mismatch fails the amend in strict mode, or is flagged in loose mode). These are configured by Routespring during onboarding; there is no self-serve config surface for them. Valid field combinations: send hotel for HOTEL bookings and flight for FLIGHT bookings (matching the booking's type); manualoverride may be sent alone or alongside. Side effect — manualoverride becomes true by default after a successful PATCH. Once set, the diff engine will no longer touch this booking on subsequent schedule submissions. To explicitly release the booking back to automatic management, PATCH with { "manualoverride": false } (alone or alongside other changes).

Cancel a booking. Routespring resolves the underlying supplier transaction and issues the cancellation, then returns 202 with the booking reflecting the outcome: CANCELLED on success, or NEEDSREVIEW if the supplier rejected the cancellation (the live ticket/room is still out there and an operator must reconcile it). Re-issuing DELETE on a NEEDSREVIEW booking retries the cancel; a booking already CANCELLED is idempotent (no second supplier call). Side effect — manualoverride becomes true. A cancelled booking is locked from the diff engine regardless of the supplier outcome; if the underlying pairing later reappears, Routespring will NOT auto-create a replacement. The airline must explicitly re-issue a new booking (e.g. by re-uploading the schedule with that pairing re-included).

Re-attempt supplier booking for a single booking. The booking must be in FAILED state — once a retry starts the booking moves to PENDING, so a re-POST while a retry is already in progress returns 409. Each accepted retry increments retrycount on the booking. The supplier call runs asynchronously; the response returns immediately with the booking in PENDING state.

Returns bookings that have failed and are scheduled for an automatic retry attempt. Each entry shows the next scheduled attempt time and the prior error.

Returns recent retry jobs plus their status (RUNNING / COMPLETED / FAILED) and aggregate counts.

Search Routespring's GDS hotel inventory by any combination of name, city, and airportcode. At least one filter must be supplied. Use this to discover a hotel's propertyid before registering it via PUT /crew/config/hotels. A propertyid found in this GDS inventory is booked via GDS; one that is not is treated as DIRECT. How the filters compose. name and city each run an independent LIKE-search against CONCAT(hotelname, address, city); airportcode instead searches the hotels located nearby the given airport (a proximity search around the airport's location). Results are unioned, deduplicated on propertyid, and sorted. This is a global lookup: results are the same regardless of the calling airline, so the path is not airline-scoped. Only hotels bookable through GDS are returned. A bearer credential is still required.