TABLE OF CONTENTS

• API Version Behavior Matrix
• The typical flow is as follows for v1.x version
• API v2.0 Workflow
• Supplier-Specific Business Rules

This section outlines the high-level workflow for changing the flight time on an existing booking. The process involves a sequence of API calls to explore options, calculate new pricing, and finally confirm the change.

API Version Behavior Matrix

Ancillary handling during flight changes differs significantly between API versions:

• API v1.x: All ancillary services (baggage, seats, meals, bundles) attached to the original booking are automatically dropped during a flight change.
• API v2.0: Supports Ancillary Auto-Move for specific supplier connections (e.g., Wano). Bundles and baggage automatically transfer to the new flight, while seats and meals require explicit reselection.

Note: Flight time change for WANO, any ancillary services attached to the original ticket will be automatically removed when a new flight change is processed in v1.x version

The typical flow is as follows for v1.x version

Step1: Retrieve Order Details (orderRetrieve)

• First, fetch the latest details of the existing order to understand its current state

Step 2: Search for Alternative Flights(orderReshop)

• Use this operation to search for and retrieve available alternative flights that meet the new travel requirements. This provides a list of new onward and/or return trip options.

Step 3: Request a Revised Price(orderReshopReprice)

• After selecting a preferred new flight from the options, call this endpoint to get a detailed and accurate revised price for the change. The response will include a new total amount, balance due amount, and a breakdown of new fares and taxes.

Step 4: Submit the Change Request(orderChange)

• Once the customer agrees to the new price, use this endpoint to formally submit the change request. This call typically includes payment information for any additional amount due.

Step 5: Check Change Status

• The result of the asynchronous change operation can be monitored in two ways:
  • Polling: Call orderRetrieve periodically; the response will reflect the updated itinerary once the change is processed and will contain a modification history.
  • Webhook Notification: Subscribe to push notifications to receive an instant update on the status of the change request (e.g., confirmed, confirm failed) without the need for polling.

API v2.0 Workflow

Step1: Retrieve Order Details (orderRetrieve)

First, fetch the latest details of the existing order to understand its current state

Step 2: Search for Alternative Flights(orderReshop)

• Description: The user searches for new flight options (different dates/times) to replace the existing flights. The API returns available replacement flight offers
• Key v2.0 Schema Addition (offers.impactedServices[]):

To guide downstream UI/UX logic, each offer in orderReshop returns an impactedServices array detailing how previously purchased ancillaries are affected under that specific replacement offer:

• serviceType / serviceName / ssrCode: Identifies the specific impacted ancillary (e.g., CPML, STND, XBAG).
• status (Universal Ancillary Status Enum):
  • REQUIRES_RESELECTION: The service entitlement is preserved, but requires explicit manual re-selection in downstream API calls (seatAvailability / serviceList). Unselected items will result in a forfeited spoilage fee.
  • FORFEITED: The service is dropped without refund (Spoilage).
  • REFUNDABLE_DROPPED: The service is dropped, but its value is refundable/creditable.
• Buyer Action Signal: must evaluate impactedServices[].status. If any item returns REQUIRES_RESELECTION, the system shall trigger Optional Step 3 (seatAvailability) and/or Optional Step 4 (serviceList) to allow passengers to reselect their choices.

Optional Step 3: New Seat Map Retrieval (seatAvailability)

• This API queries available ancillary services (meals, etc.) for the newly selected flight segments during the rebooking flow. To streamline the user experience, services that can be automatically transferred/carried forward (such as baggage) will NOT be returned.

• Standalone Service Selection: Allows passengers who previously bought standalone seats to pick new seat assignments.
• Bundle Meal Selection: If the original booking contained a Bundle with seat, this endpoint enables passengers to reselect their bundled seat choices for the new flight.

Optional Step 4: New Ancillary Retrieval (serviceList)

• This API queries available ancillary services (meals, etc.) for the newly selected flight segments during the rebooking flow. To streamline the user experience, services that can be automatically transferred/carried forward (such as baggage) will NOT be returned.

• Standalone Service Selection: Returns only the standalone SSRs that were purchased in the original booking but CANNOT be automatically carried forward, allowing passengers to reselect them (e.g., For AirAsia, standalone meal choices will only be returned if the original flight contained a purchased meal that was dropped during rebooking).
• Bundle Meal Selection: If the original booking contained a Bundle with meals, this API returns available meal choices to allow passengers to reselect their bundled meals (since custom bundle meals reset to default SSRs after rebooking).

Step 5: Price Re-calculation  (orderReshopReprice)

• After selecting a preferred new flight offer from the options, call this endpoint to get a detailed and accurate revised price for the change. If new seats, meals, or ancillaries were chosen in Step 3/4, include their selected services alongside the new flight offer in this request. The response will return a new total amount, the balance due amount.

Step 6: Submit Change Request (orderChange)

• Pass the repriced offer payload and payment details (if a balance is due) into orderChange to finalize and execute the itinerary modification with the downstream airline.

Step 7: Check Change Status (orderRetrieve)

• The result of the asynchronous change operation can be monitored in two ways:

• Polling: Call orderRetrieve periodically; the response will reflect the updated itinerary once the change is processed and will contain a modification history.
• Webhook Notification: Subscribe to push notifications to receive an instant update on the status of the change request (e.g., confirmed, confirm failed) without the need for polling.

Supplier-Specific Business Rules

The following operational rules are carrier-level business logic dictated by AirAsia (WANO Connection):

• Non-Refundable Ancillary Drop & Spoilage Policy
  • Carrier Business Logic: AirAsia allows passengers to omit or drop previously purchased ancillaries/bundles during a flight change. However, any dropped ancillary service is strictly non-refundable.
  • Operational Fact: If a passenger chooses not to reselect or carry forward a previously purchased ancillary (such as a seat or meal), the original entitlement will be unmapped from the new segment, and the paid amount will be forfeited as a non-refundable Spoilage Fee by the airline.
• Flight Type Matching Rule
  • AirAsia flight time change rules do not allow changing a direct flight itinerary into a connecting flight itinerary, or vice versa, during voluntary flight changes.
• Ancillary Auto-Resell & Reselection Matrix