GetReservationByItineraryIdOperationParams

IP address of the customer, as captured by your integration.
Ensure your integration passes the customer's IP, not your own. This value helps determine their location and assign the correct payment gateway.
Also used for fraud recovery and other important analytics.

Insert your own unique value for each user session, beginning with the first API call. Continue to pass the same value for each subsequent API call during the user's session, using a new value for every new customer session.
Including this value greatly eases EPS's internal debugging process for issues with partner requests, as it explicitly links together request paths for individual user's session.

Email associated with the booking. Special characters in the local part or domain should be encoded. (Email is required if the token is not provided the request)

Options for which information to return in the response. The value must be lower case. * history - Include itinerary history, showing details of the changes made to this itinerary. Changes from the property/supplier have an event_source equal to other in the response. * history_v2 - Include itinerary history, showing details of the changes made to this itinerary. Changes from the property/supplier have an event_source equal to supplier in the response. See the Itinerary history for details.

This parameter is used only to prefix the token value - no ID value is used.

The retrieve call has a test header that can be used to return set responses. Passing standard in the Test header will retrieve a test booking, and passing any of the errors listed below will return a stubbed error response that you can use to test your error handling code. Additionally, refer to the Test Request documentation for more details on how these header values are used. * standard - Requires valid test booking. * service_unavailable * internal_server_error

Provided as part of the link object and used to maintain state across calls. This simplifies each subsequent call by limiting the amount of information required at each step and reduces the potential for errors. Token values cannot be viewed or changed.

IP address of the customer, as captured by your integration.
Ensure your integration passes the customer's IP, not your own. This value helps determine their location and assign the correct payment gateway.
Also used for fraud recovery and other important analytics.

Insert your own unique value for each user session, beginning with the first API call. Continue to pass the same value for each subsequent API call during the user's session, using a new value for every new customer session.
Including this value greatly eases EPS's internal debugging process for issues with partner requests, as it explicitly links together request paths for individual user's session.

Email associated with the booking. Special characters in the local part or domain should be encoded. (Email is required if the token is not provided the request)

Options for which information to return in the response. The value must be lower case. * history - Include itinerary history, showing details of the changes made to this itinerary. Changes from the property/supplier have an event_source equal to other in the response. * history_v2 - Include itinerary history, showing details of the changes made to this itinerary. Changes from the property/supplier have an event_source equal to supplier in the response. See the Itinerary history for details.

This parameter is used only to prefix the token value - no ID value is used.

The retrieve call has a test header that can be used to return set responses. Passing standard in the Test header will retrieve a test booking, and passing any of the errors listed below will return a stubbed error response that you can use to test your error handling code. Additionally, refer to the Test Request documentation for more details on how these header values are used. * standard - Requires valid test booking. * service_unavailable * internal_server_error

Provided as part of the link object and used to maintain state across calls. This simplifies each subsequent call by limiting the amount of information required at each step and reduces the potential for errors. Token values cannot be viewed or changed.