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.

1.5 Markup source changed

• Pricing no longer relies on fixed global constant markup.
• Markup is resolved from markup inventory per itinerary:
  • specific-trip markup (highest priority)
  • else all-trips markup
  • else no markup
• Both markup types are supported in pricing:
  • Percentage
  • Flat

---

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) Markup management APIs (admin)

Base: /v1/markup

• POST /v1/markup create markup
• PUT /v1/markup/:id update markup
• DELETE /v1/markup/:id soft delete markup
• GET /v1/markup list markups
• GET /v1/markup/:id get markup details
• GET /v1/markup/unmapped-itineraries list trips not mapped in any specific markup

Behavior rules:

• trip can belong to only one specific markup (tenant scope)
• one all-trips markup per tenant
• all-trips markup cannot be deleted (only update)
• list/detail responses include normalized appliesTo structure:
  • ALL_TRIPS
  • SPECIFIC_TRIPS with tripIds and trips[]

5.1 Create specific-trip markup

POST /v1/markup

{
  "name": "Summer promo - selected trips",
  "isGlobal": false,
  "itineraryIds": [948, 950, 958],
  "type": 2,
  "amount": 7.5,
  "notes": "Percentage markup for selected trips",
  "isActive": true
}

5.2 Create all-trips markup

POST /v1/markup

{
  "name": "Default all-trips fallback",
  "isGlobal": true,
  "type": 1,
  "amount": 1200,
  "notes": "Flat fallback markup for all trips",
  "isActive": true
}

5.3 Update markup

PUT /v1/markup/:id

{
  "name": "Summer promo - revised",
  "isActive": true,
  "type": 2,
  "amount": 8.25,
  "notes": "Revised percentage",
  "addItineraryIds": [970],
  "removeItineraryIds": [950]
}

5.4 Normalized list/detail response (appliesTo)

{
  "id": 12,
  "name": "Summer promo - revised",
  "isGlobal": false,
  "type": 2,
  "amount": "8.25",
  "isActive": true,
  "appliesTo": {
    "type": "SPECIFIC_TRIPS",
    "tripIds": [948, 958, 970],
    "trips": [
      { "id": 948, "name": "Sikkim Delight" },
      { "id": 958, "name": "North East Premium" },
      { "id": 970, "name": "Bhutan Escape" }
    ]
  }
}

For all-trips markup:

{
  "appliesTo": {
    "type": "ALL_TRIPS",
    "tripIds": [],
    "trips": []
  }
}

---

6) 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