A traveler asks to postpone the outbound flight by two days while keeping the return. An “Edit” button may start quotation, await approval or route manual provider work. These distinctions change travel-platform development scope beyond adding a new date screen.
Before pricing, define supported bookings and changes, automated actions and staff follow-up. Require evidence of the actual integration provider's limits rather than assuming every ticket can be changed identically.
Start with a booking partly unchanged
Imagine a fictional corporate travel platform where an employee postpones outbound travel and retains the return. A change offer may expire before managerial approval. This illustrates scope questions without a real booking, passenger or price.
Identify the booking, travelers, changed and preserved journey parts, request authority and approval ownership. An updated date in the employee account cannot establish an airline booking change. Internal managerial approval is also distinct from provider confirmation.
A matrix separating requests and confirmation
Use these proposed states to define meaning for customers and follow-up staff. The implementer should map them to actual provider states and evidence, identifying anything that cannot be established.
| State | Meaning in the proposed journey | Do not infer |
|---|---|---|
| Change request | Requested changes and ownership are recorded | Alternative-flight availability or final pricing |
| Change offer | An alternative with conditions, amount, currency and expiry | A changed booking or guaranteed continued availability |
| Pending change | A selection awaiting provider-defined confirmation | Confirmation or completed settlement |
| Evidenced confirmation | References establish actual changes | Automatic closure of every ancillary or refund |
| Manual follow-up | An owner and next step for nonautomated work | Necessary rejection or completion merely through referral |
Duffel separates change offers, pending changes and confirmation. It also exposes booking conditions and available API actions, explaining that permitted changes may not always be executable through its API. These are provider-specific examples rather than universal carrier or contract coverage.
What happens when an offer expires?
Request a case where approval arrives after expiry. What does the employee see, who obtains alternatives, and do revised amounts or conditions require fresh approval? Old authorization should not silently apply to a materially changed result.
Also review simultaneous requests or external booking modifications during waiting. The objective here is preserving change context and state evidence rather than prescribing one concurrency or retry mechanism. Provider and implementer should explain verifiable facts and remaining uncertainty.
Separate financial effects from itinerary state
Identify provider-supplied amounts, currencies and components, review authority, approval and platform collection/follow-up work. “Change permitted” cannot establish free changes, while positive or negative values cannot become a universal booking policy.
Confirmation documentation explains that provider-side returned funds may still require a customer-refund step. Separate itinerary state from collection and refund status, assigning each follow-up. This example establishes neither legal refund rights nor guaranteed fees or processing times.
Provide a route for manual work
If integration does not support a change, identify the follow-up team, reference, required information, next action and waiting-state message. Avoid stranding requests because no automated button exists. Referring work cannot independently establish carrier acceptance.
Distinguish passenger-initiated changes from airline-initiated changes, whose options, approvals and notices may differ. Before accepting a quote, request included and excluded cases with evidence sources, plus safe expired-offer, successful-confirmation and manual-follow-up examples using authorized test data.
Review third-party dependencies and the integration pricing brief, then attach the change matrix when requesting a web platform from Nextwave so work beyond the screen appears in scope.
References and coverage boundaries
Specific Duffel sections on change offers, changes and confirmation, and booking conditions and actions were opened on 4 November 2026. The matrix and example are proposals without actual booking, API use, collection or messaging. AI assisted preparation, with information and translation review.
