Routespring publishes Crew Travel API v1 documentation

What the documentation covers

The documentation explains how airline-owned crew schedules and disruption decisions can be connected to policy-aware hotel and deadhead execution. It also defines the human boundary for policy holds, unavailable inventory, price exceptions, supplier failures, and other cases that require review.

The current v1 documentation covers:

• crew schedule submissions
• action items
• configuration
• hotel and deadhead booking workflows
• changes and cancellations
• status refresh
• safe retries
• audit events
• hotel inventory
• booking exports
• OAuth2 authentication
• an OpenAPI 3.1 contract

Three implementation guides based on operating outcomes

The documentation includes three implementation guides designed around airline workflows rather than isolated endpoints.

Scheduled crew bookings

The scheduled-bookings guide shows how to submit a complete roster window, preserve airline identifiers, apply configured controls, inspect derived actions, and return review or failed states to an owned exception queue.

Follow the scheduled-bookings tutorial

IROPS recovery

The IROPS guide shows how an airline-owned disruption decision can create correlated hotel and deadhead requirements under one IROPS reference. The airline continues to own event detection and operational judgment.

Follow the IROPS tutorial

Reconciliation-ready booking records

The reconciliation guide shows how operational anchors, booking identifiers, supplier confirmations, rates, status history, and exports can create a stronger handoff into the financial process.

Follow the reconciliation tutorial

Built for operational clarity

The developer section is intended to help airline teams answer four implementation questions before production code becomes the plan:

1. Which airline system creates the source event?
2. Which identifiers must remain attached across systems?
3. Which outcomes can move automatically and which require a person?
4. Which records must be retained for operations, support, procurement, and finance?

This operating context is important because a technically valid API call is not, by itself, a complete airline workflow.

Current capabilities are separated from planned API families

The API roadmap separately identifies planned families for event delivery, invoice and folio ingestion, ground transport, payment issuance, supplier contracts, and crew profiles.

These planned capabilities are not part of the current v1 contract and may change before release. Implementation teams should treat the published API reference and OpenAPI contract as the source of truth for current availability.

Where to begin

Airline operations and technology leaders can begin with the buyer-facing Crew Travel API overview. Developers can continue directly to the documentation and quickstart.