Frontend API Change Impact Guide

This guide summarizes what frontend consumers need to change after recent pricing/import updates.

Scope

Applies to:

• pricing page flows (admin + customer)
• full import itinerary flow
• inventory pre-check/search flows for hotel/transfer

---

1) Pricing API updates

1.1 Admin vs Customer write endpoints

Use separate endpoints for pricing-selection save:

• Admin: PUT /v1/itinerary/:id/pricing-selection (JWT + TRIP permission)
• Customer: PUT /v1/itinerary/:id/customer-pricing-selection (booking-jwt)

Both return pricing response in the same shape as GET /v1/itinerary/:id/price-details.

1.2 Category values

Category fields are numeric enum values (not string labels):

• 1 = LUXURY
• 2 = PREMIUM
• 3 = SUPER_DELUXE
• 4 = DELUXE
• 5 = STANDARD

1.3 Slab banding rule

Vehicle slab auto-selection uses adults + children (infants excluded):

• <= 3 => 1-3 slab
• > 3 => 4-6 slab (or higher matching slab)

1.4 defaultHotelCategory removed

• Do not read or send defaultHotelCategory.
• Use tripType as canonical category source.

---

2) Import Full Itinerary payload updates

Endpoint: POST /v1/itinerary/import-itinerary-full

2.1 Inventory references

Use IDs only:

• hotelIds: number[]
• transferIds: number[]

Do not send old hotels[] / transfers[] create-resolve payloads.

2.2 Activities

activities[] are created and mapped day-wise.

Required fields per item:

• dayOrder (number)
• title (string)
• startTime (string, mandatory)

Optional fields:

• duration (minutes)
• description, catgType, subCatgType, activityType, latitude, longitude

2.3 Hotel day-wise mapping

Explicit mapping supported via:

• hotelDayMappings: [{ hotelId, dayOrder }]

Validation:

• day must exist
• hotel must exist
• day location must match hotel city/location

Backward compatibility:

• if hotelDayMappings is omitted, backend maps hotel to all itinerary days with matching location.

2.4 Transfer mapping

• Transfer remains itinerary-wise only (not day-wise).

---

3) Inventory APIs response enrichments

3.1 Hotel inventory responses (import-related)

For check-inventory, search-inventory, and inventory responses, hotel objects now include:

• id, name, cityId, category
• address, description, starRating, checkInTime, checkOutTime, roomType

POST /v1/hotel/check-inventory also returns:

• hotels: [] (all matched priority-name hotels)
• hotel (first match for backward compatibility)

3.2 Transfer inventory responses (import-related)

For check-by-name, search, and inventory responses, transfer objects now include:

• id, vehicleName, vehicleType, seater
• description, notes, isActive, createdAt, updatedAt

POST /v1/transfer/check-by-name request is bulk:

{ "items": [{ "name": "Wagon R / Similar" }, { "name": "Innova / Similar" }] }

Response includes requestedName per item.

---

4) Existing GET APIs and break-risk

The following endpoints are not route-changed by these updates:

• GET /v1/itinerary/agent
• GET /v1/itinerary
• GET /v1/itinerary/:id
• GET /v1/hotel/itinerary/:id
• GET /v1/transfer/itinerary/:id/transfers
• GET /v1/days/itinerary-details/:id

Potential response/data adjustments frontend should tolerate:

• defaultHotelCategory field removal
• updated tripType category interpretation
• richer day-wise hotel/activity data for newly imported itineraries

---

5) Frontend checklist

• Switch customer pricing save to PUT /v1/itinerary/:id/customer-pricing-selection
• Keep admin pricing save on PUT /v1/itinerary/:id/pricing-selection
• Send numeric category enums (1..5), not labels
• Update import payload to hotelIds, transferIds, activities, optional hotelDayMappings
• Include startTime for each imported activity
• Handle enriched hotel/transfer response fields
• Remove any usage of defaultHotelCategory