Changes for page SearchTourPackages - Basic Version

Summary

• Page properties (2 modified, 0 added, 0 removed)

Details

Page properties

Title

...	...	@@ -1,1 +1,1 @@
1		-SearchTourPackages - Basic Version
	1	+SearchTourPackages - Basic version

Content

...	...	@@ -6,32 +6,11 @@
6	6
7	7	= Method Description =
8	8
	9	+Tour package mean, tour with hotel and flight together. Using this method gives data about full package availability with flight and hotel options.
9	9
10		-=== Method Overview: Streamlined Tour Package Discovery and Booking ===
	11	+It's possible to receive data as current dates, also in date ranges using parameter  "stayDays": 0,   "stayDaysTo": 0. the maximum difference between the days can be 7. Below you can see examples.
11	11
12		-**Purpose:** This method outlines the most efficient process for locating and subsequently booking a tour package utilizing a minimal set of required parameters. It is designed to simplify the user interaction by reducing the complexity and volume of input data necessary for operation.
13	13
14		-**Procedure:**
15		-
16		-1. **Initialization**: Start by specifying the essential parameters. This approach is engineered to streamline the search and booking process, focusing on the core data elements critical for identifying suitable tour packages.
17		-1. **Search Execution**: Deploy the method with the specified parameters to initiate the search. The system is optimized to process these inputs, conducting a targeted query across available tour packages to identify matches that align with the user's criteria.
18		-1. **Selection and Booking**: Upon receiving search results, the user can select a desired tour package. The booking process is then initiated with the minimal parameters already provided, ensuring a seamless transition from selection to confirmation.
19		-
20		-**Parameter Details:**
21		-
22		-* The parameters required for this method are intentionally limited to essential elements only, aiming to expedite the search and booking phases while maintaining effectiveness. Details on these parameters, including data types and usage instructions, are documented separately.
23		-
24		-**Usage Notes:**
25		-
26		-* This method is particularly beneficial for users seeking a straightforward and efficient path to tour package booking, minimizing decision fatigue and enhancing user experience.
27		-
28		-**Examples:**
29		-
30		-* Code examples and detailed step-by-step instructions for utilizing this method are available in the subsequent sections, providing practical guidance on implementing the streamlined tour package discovery and booking process.
31		-
32		-This documentation segment aims to facilitate developers and users in leveraging a simplified method for tour package exploration and booking, ensuring an efficient and user-friendly interaction with the system.
33		-
34		-
35	35	== Endpoint URL - [POST] ==
36	36
37	37	{{info}}
...	...	@@ -67,7 +67,7 @@
67	67	}
68	68	{{/code}}
69	69
70		-== Request example for 2Adults 2Child ==
	49	+== Request example 2Adults 2Child ==
71	71
72	72	{{code language="Json"}}
73	73	{
...	...	@@ -88,7 +88,7 @@
88	88	"checkInAndCheckOutDaysCount": 7,
89	89	"directFlightsOnly": true,
90	90	"searchCurrency": "USD",
91		-
	70	+
92	92	"pagingId": "",
93	93	"pageNumber": 1,
94	94	"pageRowCount":5
...	...	@@ -779,6 +779,8 @@
779	779	|pageRowCount|Integer|No|The number of results to return per page. For example, 1 to return 1 result per page.
780	780	|searchCurrency|String|No|The currency in which the search results should be displayed. For example, "USD" for United States Dollar.
781	781
	761	+=== ===
	762	+
782	782	=== **Response Parameters** ===
783	783
784	784	(% class="table-bordered" %)
...	...	@@ -785,7 +785,7 @@
785	785	|=Key|=Type|=Description
786	786	|packages|Array|An array of travel packages. Each package includes various details about the package.
787	787	|packages[].id|String|A unique identifier for the package. This is used to uniquely identify each package.
788		-|packages[].priceCurrency|String|The currency in which the price is denoted. This could be •   KZT - ₸ •   USD - $ •   RUB - ₽ •   EUR - € •   UZS - ЛВ •   AZN - ₼.
	769	+|packages[].priceCurrency|String|The currency in which the price is denoted. This could be USD, EUR, etc.
789	789	|packages[].totalPrice|Number|The total price of the package. This includes all costs associated with the package.
790	790	|packages[].agentCommissionPercent|Number|The commission percentage for the agent. This is the percentage of the total price that the agent receives as commission.
791	791	|packages[].agentCommissionAmount|Number|The commission amount for the agent. This is the actual amount the agent receives as commission.
...	...	@@ -840,7 +840,7 @@
840	840	|packages[].flight.isTwoWay|Boolean|A boolean indicating if the flight is two-way. If true, it means that the flight includes both departure and return.
841	841	|packages[].flight.sameBaggageForAll|Boolean|A boolean indicating if the same baggage is for all. If true, it means that the same baggage allowance applies to all passengers.
842	842	|packages[].flight.totalBaggage|Boolean|A boolean indicating if total baggage is included. If true, it means that the total baggage allowance is included in the price.
843		-|packages[].flight.isBlock|Boolean|A boolean indicating if the flight is block or not. If true, it means that the flight is currently block of flights
	824	+|packages[].flight.isBlock|Boolean|A boolean indicating if the flight is blocked. If true, it means that the flight is currently blocked and cannot be booked.
844	844	|packages[].flight.class|String|The class of the flight. This could be economy, business, first class, etc.
845	845	|packages[].flight.departureSegments|Array|An array containing details about the departure segments. Each segment includes information like the departure airport, arrival airport, departure time, arrival time, etc.
846	846	|packages[].flight.returnSegments|Array|An array containing details about the return segments. Each segment includes information like the departure airport, arrival airport, departure time, arrival time, etc.
...	...	@@ -869,12 +869,10 @@
869	869	}
870	870	{{/code}}
871	871
872		-While making first search request, paging id should be empty,  "pageNumber":  and  "pageRowCount":10 means that, in response there will be returned maximum 10 packages per page.
873	873
874		-
875	875	==== Request with caching ====
876	876
877		-after receiving response from first search request, in the end we can see pagingId- number, wchich we can use for caching, and (pageinatoin) for switch pagenumbers, and displaying results as we whant. For cleaning cache, it's important to make new request without cllear pagingID, like this  "pagingId": "",
	856	+as we receive response, in the end we can see pagingId- number, chich we can use for caching, and then just switch pagenumbers. for cleaning cache, it's important to make new request without pagingID
878	878
879	879	{{code language="Json"}}
880	880	{
...	...	@@ -885,56 +885,6 @@
885	885	{{/code}}
886	886
887	887
888		-**Overview:** The Paging and Caching mechanism is designed to efficiently manage data retrieval in a paginated format. This mechanism is essential for handling large datasets by dividing the data into manageable pages, thereby optimizing the performance and scalability of data retrieval operations.
889		-
890		-**Initial Request:**
891		-
892		-* **Purpose**: The first request initiates the paging process and is designed to fetch the initial set of data without utilizing a pagingId.
893		-* **Parameters**:
894		-** pagingId: Should be set to an empty string ("") to indicate that this is the initial request.
895		-** pageNumber: Indicates the specific page of data to retrieve, starting with 1.
896		-** pageRowCount: Specifies the number of results to be included on each page.
897		-
898		-**Example - First Request**:
899		-
900		-{{{{
901		- "pagingId": "",
902		-  "pageNumber": 1,
903		-  "pageRowCount": 10
904		-}
905		-}}}
906		-
907		-
908		-**Subsequent Requests with Caching:**
909		-
910		-* **Purpose**: Following the initial data retrieval, subsequent requests utilize the pagingId obtained from the previous response. This pagingId serves as a cache identifier, enabling the system to quickly access the relevant dataset and efficiently paginate through the data.
911		-* **Cache Utilization**:
912		-** Upon receiving a response, a pagingId value is provided. This pagingId should be used in subsequent requests to reference the cached data.
913		-** To navigate through the dataset, adjust the pageNumber while keeping the pagingId constant.
914		-** To refresh the dataset and clear the cache, initiate a new request without a pagingId.
915		-
916		-**Example - Request with Caching**:
917		-
918		-{{{ {
919		- "pagingId": "80",
920		- "pageNumber": 2, // Adjusted to fetch the next page
921		- "pageRowCount": 10
922		- }
923		-}}}
924		-
925		-
926		-**Cache Management:**
927		-
928		-* Clearing the cache and fetching a fresh set of data requires sending a new request with the pagingId parameter omitted or set to an empty string. This action resets the pagination and caching context.
929		-
930		-**Implementation Notes**:
931		-
932		-* The paging and caching mechanism significantly enhances data retrieval efficiency by minimizing server load and optimizing response times.
933		-* Developers should ensure that the pagingId is correctly managed between requests to maintain session continuity and data consistency.
934		-
935		-This documentation outlines the procedural framework for implementing a robust paging and caching strategy within data retrieval systems, detailing parameter usage and operational best practices for both initial and subsequent data fetch operations.
936		-
937		-
938	938	=== search parameter options ===
939	939
940	940	in the request body it's available to filter search results with parameters. parameter examples:
...	...	@@ -973,39 +973,22 @@
973	973	{{/code}}
974	974
975	975
976		-1. **RO (Room Only)**: This plan includes only the accommodation with no meals provided. Guests will need to arrange their own meals either outside the hotel or by purchasing them separately within the hotel.
977		-1. **BB (Bed and Breakfast)**: This plan includes accommodation along with breakfast served at the hotel. No other meals are included, which means guests need to arrange their own lunch and dinner.
978		-1. **HB (Half Board)**: This meal plan includes accommodation along with two meals a day, typically breakfast and either lunch or dinner. Guests can choose which two meals are most convenient for them based on the options provided by the hotel.
979		-1. **FB (Full Board)**: Under the full board plan, accommodation and all three meals (breakfast, lunch, and dinner) are included. This plan is convenient for guests who do not wish to worry about arranging meals during their stay.
980		-1. **AL (All Inclusive)**: The all-inclusive meal plan includes accommodation, all meals (breakfast, lunch, dinner), and usually includes a range of snacks and beverages (both alcoholic and non-alcoholic). It is the most comprehensive meal plan, offering the greatest convenience and predictability in costs.
981	981
982		-
983	983	== Important ==
984	984
985	985	{{error}}
986		-=== Implementing Authorization in Subsequent Requests ===
	909	+It's Important to in every other request header, put Auth token
987	987
988		-For every API request after the initial authentication, it's crucial to include the authorization token in the request header. This ensures your requests are authorized and can access the necessary resources. Here's how to properly include your token:
	911	+**Key **- Authorization
989	989
990		-* **Header Key:** Authorization
991		-* **Header Value:** Bearer [Your Token Here] - Use the bearer token provided in the initial authentication response. The authorization type should be specified as Bearer Token.
	913	+**Value **- Bearer Token what is given in this response.
992	992
993		-Additionally, to ensure your requests are properly formatted and recognized, include the following headers:
994	994
995		-* **Content-Type:** Specify this header as application/json to indicate the format of the request body.
996		-* **Header Key:** X-nugios-timezone
997		-* **Header Value:** 240 - Adjust this value to match your local timezone offset in minutes.
	916	+**also note in headers that:**
998	998
999		-Incorporating these headers with their respective values is essential for the successful processing of your API requests.
1000		-{{/error}}
	918	+Content-Type - application/json
1001	1001
	920	+**Key - **X-nugios-timezone
1002	1002
1003		-
1004		-(% class="box errormessage" %)
1005		-(((
1006		-Tour package requirements can vary based on the destination country, necessitating the inclusion of additional mandatory services such as Visa, Insurance, etc. When querying for tour packages through the API, the response payload will dynamically include fields indicating whether these services are mandatory. For instance, the API may return a structure like this:
1007		-
1008		-[[image:https://xwiki.nugios.com/xwiki/bin/download/APIs/Online%20API/TourPackages/WebHome/1713191255012-154.png?rev=1.1||alt="1713191255012-154.png"]]
1009		-
1010		-in the given example it means that insurance service is mandatory for the tourpackage.
1011		-)))
	922	+**Value **- 240
	923	+{{/error}}