CRUISEHOST Knowledge Base

CRUISEA is the professional B2B cruise search, sales and booking platform from CRUISEHOST. It gives travel professionals access to cruise content, availability, prices, offers, customer management and booking functions within one system.

CRUISEA is designed for travel agencies, cruise specialists, home-based agents, call centres, host agencies, tour operators and other professional cruise sellers.

CRUISEA is primarily a professional B2B system for travel sellers. Customer-facing cruise search and booking functions are normally provided through CRUISEC.

Depending on the available cruise content, you can search using a wide range of criteria, including:

• Cruise line
• Ship
• Destination
• Departure port
• Arrival port
• Travel date
• Travel duration
• Cabin category
• Price range
• Number of passengers
• Itinerary
• Country
• Region
• Port of call
• Special offers
• Included services
• Onboard features
• Ship characteristics
• Suitable customer groups

Yes. CRUISEA provides a large number of search and filtering options to help travel professionals identify suitable cruises quickly and accurately.

Yes. Depending on the licence and configuration, CRUISEA can provide map-based cruise search functions in addition to traditional result lists.

Yes. Cruises can be collected, reviewed and presented to the customer as part of the offer process.

Yes, for cruise lines connected through live booking interfaces. Availability, cabin categories and prices can be requested directly from the relevant cruise line system.

Not necessarily. Some content may be based on catalogue or cached prices, while final availability and pricing are confirmed through a live request to the cruise line. The exact process depends on the cruise line connection.

Yes. For supported cruise lines and booking connections, travel agents can complete bookings through CRUISEA.

Yes. Where supported by the cruise line, an option can be created before the final booking is confirmed. CRUISEHOST also offers SmartOption for selected sales processes. From 11 August 2026, SMART OPTION is available for all TYPE 2 packages regardless of cruise line when the dummy cruise line CEX is enabled in the agency's CRUISEA Settings. Cruise-line SmartOption activation remains relevant for API bookings, including TYPE 3 packages that actively book into the cruise-line API.

Yes. Depending on the licence, CRUISEA can create professional PDF offers that can include selected cruises, itineraries, prices, ship information and agency contact details.

Yes. Depending on the selected licence, your logo, agency details and signature information can be included in customer-facing documents.

Yes. Selected licences include functions for creating cruise offers, PDF documents and promotional material.

The WatchList allows a travel agent to collect selected cruise offers during the search process. These offers can then be reviewed, compared and used to create customer presentations such as SmartOffer 360.

Yes. CRUISEA includes CRM functions for storing and managing customer information.

Yes. Offers, WatchLists, SmartOffer 360 presentations, options and bookings can be created in connection with a customer record.

Yes. Bookings created through CRUISEA, CRUISEC or connected CRUISEHOST solutions can be made available in the booking-management area, depending on the configuration.

Available functions may include:

• View booking details in clearly separated tabs
• Review passenger information and contact details
• Open booking confirmations
• Resend documents
• Access payment information
• View booking status and History information
• Manage options and SmartOptions
• Edit eligible options when the EDIT button is available
• Confirm and update eligible options
• Use REBOOK for eligible ON REQUEST bookings
• Access booking PDFs
• Communicate about bookings
• Transfer booking information to connected systems

Yes, where supported by the cruise line and booking status. When the EDIT button appears, the travel agent can edit an OPTION or SmartOption, including passenger names and contact details. After the changes have been completed, the option can be processed using Confirm + Update. Availability of the EDIT function depends on the cruise line.

Depending on the booking and system configuration, documents such as booking confirmations can be opened or resent from the booking area.

CRUISEA includes customer, offer and booking-management functions, but whether it replaces an existing back-office system depends on the requirements of the customer. CRUISEHOST can also provide interfaces to external back-office systems.

Yes. Multiple users can be created according to the selected licence and commercial agreement.

User access and available functions can be configured according to the organisation, licence and role structure.

Yes. Single sign-on integrations may be provided so that authorised users can access CRUISEA through another platform without a separate manual login.

CRUISEAfree is the free entry-level version of the CRUISEA professional cruise sales platform.

CRUISEAfree is suitable for travel professionals who want to explore CRUISEHOST, search cruise content and become familiar with the CRUISEA environment before selecting a larger licence.

CRUISEAfree normally includes one user.

Yes. CRUISEAfree provides access to cruise search functions within the available market and catalogue configuration.

Live availability may be available for connected cruise lines, subject to the market, cruise line access and account configuration.

The available booking functions depend on the account configuration, connected cruise lines and contractual setup. Test or API accounts may use dummy cruise-line access and softbooking processes instead of transmitting confirmed bookings to the cruise line.

Yes. CRUISEAfree can be upgraded to CRUISEAlight, CRUISEA or another suitable CRUISEHOST licence.

Normally, the existing account can be extended so that available customer, offer and account information remains accessible. The exact migration depends on the account setup.

CRUISEAlight is an extended entry-level version of CRUISEA. It provides additional professional sales and presentation functions beyond CRUISEAfree.

Depending on the current licence definition, CRUISEAlight can include functions such as:

• PDF creation
• Agency logo integration
• Agency signature information
• Map-based cruise search
• Connections to supported external offer systems
• Additional customer-facing sales tools

Yes. CRUISEAlight can be used as part of a host-agency or subagency model, depending on the commercial and technical configuration.

SmartOffer 360 is an interactive customer-offer solution that allows travel agents to transform selected cruises from the CRUISEA WatchList into a professional online presentation.

The travel agent searches for cruises in CRUISEA, adds suitable offers to the WatchList, selects the customer and creates a SmartOffer 360 presentation.

The customer receives a link to an interactive offer page that can display the selected cruises, itineraries, prices, ship information, images and booking-related actions.

Yes. Depending on the configuration, the customer can receive both an interactive SmartOffer 360 link and a corresponding PDF presentation.

Yes. The link can be shared by email or through other communication channels.

Yes. The SmartOffer 360 link can be sent through WhatsApp, provided that the travel agency uses WhatsApp in accordance with its own data-protection and communication policies.

SmartOffer 360 can provide access to current availability and price information where supported. Final prices and availability must always be reconfirmed through the connected cruise-line system.

The customer can use the available booking or enquiry action to continue to the travel agency’s booking environment or contact the travel agent. The exact process depends on the customer configuration.

No. SmartOffer 360 supports the travel agency’s sales process. The customer continues through the configured travel-agency or booking environment.

Yes. A SmartOffer 360 presentation can contain several selected cruise alternatives.

Yes. The presentation can be connected to a customer record and can include the travel agency’s branding and contact information.

Depending on the offer status and configuration, the travel agent can revise the selected cruises or create a new SmartOffer 360 presentation.

SmartOption is designed for situations in which a travel agent wants to create a cruise option before all final passenger information is available.

From 11 August 2026, SMART OPTION is available for all TYPE 2 packages regardless of cruise line. To enable this functionality, the dummy cruise line CEX must be activated in the agency's CRUISEA Settings.

This TYPE 2 activation is separate from cruise-line SmartOption activation. Cruise-line SmartOption activation refers to API bookings, including TYPE 3 packages that actively book into the cruise-line API.

A customer may be interested in a cruise but still need to discuss the decision with another traveller. SmartOption allows the travel agent to secure an eligible option using the limited information permitted by the process.

The required information depends on the cruise line and configuration. In certain SmartOption processes, only a name and email address may initially be required for each option.

Where supported, a travel agent can create more than one option so that the customer can compare alternatives before deciding which cruise to confirm.

An option is only valid for the period and under the conditions confirmed by the cruise line. The option may expire automatically if it is not confirmed in time.

The travel agent can provide an option confirmation, for example as a PDF, and can send it to the customer by email or another agreed communication channel.

The travel agent opens the option in CRUISEA. If the cruise line supports editing and the EDIT button is available, passenger names and contact details can be completed or corrected. The travel agent can then use Confirm + Update to process the option, provided the option is still valid and confirmation is permitted.

Normally, all passenger information required by the cruise line must be completed before final confirmation. Requirements vary by cruise line, destination and booking type.

REBOOK is a CRUISEA function for bookings with the status ON REQUEST. It is designed for situations in which a cruise line does not permit the requested OPTION, for example because option availability is restricted during high season or the cruise line only allows confirmed bookings at certain points.

Instead of entering the booking again manually in the cruise line booking system, the travel agent can start REBOOK directly from the ON REQUEST booking in CRUISEA.

Use REBOOK when CRUISEA attempted to create an OPTION but the cruise line denied it and the booking remains with the status ON REQUEST. The detected error can be reviewed in the HISTORY tab of the CRUISEA booking.

CRUISEA steps through the booking process automatically and tries to obtain the same fare, category and cabin number that are stored in the ON REQUEST booking.

If one of these elements is no longer available, CRUISEA stops at the relevant point and asks the travel agent to choose an alternative or confirm the suggestion shown on screen.

Once the booking has been successfully recreated, it remains in CRUISEA and can be processed like other bookings available in the booking-management area. The purpose of REBOOK is to reduce duplicate workload and keep the booking process in one system.

The booking-detail view in CRUISEA is organised into tabs for the different sections of the booking. This makes it easier to navigate between booking information, passenger details, history and other available sections without working through one long booking page.

The redesigned booking details were introduced in preparation for functions such as editing OPTION and SmartOption passenger information.

Yes, when the cruise line supports this function. As soon as the EDIT button is available for the booking, the travel agent can edit an OPTION or SmartOption, including passenger names and contact details.

The availability of the EDIT button depends on the cruise line and the relevant booking conditions.

After eligible passenger names or contact details have been edited, Confirm + Update is used to continue the option process with the updated information. The function is available only where the cruise line and booking status permit it.

Yes. CRUISEA includes functions for creating and managing customer records.

Yes. WatchLists, SmartOffer 360 presentations, options and bookings can be linked to customer records.

Passenger and traveller information can be managed according to the available CRM and booking functions.

Customer-data imports may be possible as part of an implementation or integration project. The required format and data-protection requirements must be agreed in advance.

Exports or transfers may be available through system functions or BACKOFFICE interfaces, subject to user permissions and contractual requirements.

Yes. Booking and sales information can be made available through system views, exports or individual reports.

Depending on the available data, reports may include:

• Number of bookings
• Booking revenue
• Travel agency
• User
• Market
• Cruise line
• Booking channel
• Booking date
• Departure date
• Offer type
• Commission
• Booking status

Yes. Reporting can cover periods such as today, yesterday, month to date, year to date, previous months, previous years or rolling periods.

Exports may be available in formats such as CSV or through customer-specific reporting interfaces.

Yes. Customer-specific reports can be reviewed and developed as an additional service.

CRUISEC is the customer-facing B2C cruise search and booking engine from CRUISEHOST. It enables travel companies to offer cruise search, cruise information, availability and booking functions on their own websites.

CRUISEC is suitable for:

• Travel agencies
• Cruise specialists
• Online travel agencies
• Tour operators
• Host agencies
• Travel agency chains
• Affiliates
• Companies launching a new cruise website

Yes. CRUISEC can be supplied as a full-page solution or integrated into an existing website, for example through an iframe or other supported implementation method.

Yes. CRUISEC can be implemented under a customer domain or subdomain, depending on the selected setup.

Domain and hosting services may be included or arranged as part of the implementation, depending on the selected package.

Yes. Colours, logos, fonts, navigation elements and other visual components can be adapted through the standard CRUISEC configuration. More advanced design changes can be made with CSS CUSTOMIZER in PAGEMAKER.

CRUISEC is designed for use on modern desktop, tablet and mobile devices. The final presentation may also depend on the surrounding customer website and implementation.

Yes. Customers can search and filter cruise offers using the content and functions enabled for the website.

Yes, for supported cruise lines and booking connections. Live prices, cabin categories and availability can be requested during the customer journey.

Yes. Depending on the cruise line, market and customer configuration, bookings can be completed online through CRUISEC.

Where supported, a cruise may be held as an option before final confirmation. The option period and rules are determined by the cruise line.

Bookings created through CRUISEC can be made available in the CRUISEA booking-management area and may also be transferred to connected back-office systems.

This depends on the commercial and technical setup. Payment may be made directly to the cruise line, to the travel agency, to a tour operator, to a host agency or to another authorised merchant.

Yes. Payment-provider integrations may be provided through PAYMENT PROFESSIONAL.

Yes. The cruise-line portfolio can be configured according to the customer’s contracts, market, commercial model and technical availability.

Depending on the product, cruise line and commercial model, individual price calculations, packages, mark-ups, discounts or other sales rules can be configured.

Yes. Depending on the setup, customer-specific packages and additional services can be included in the cruise catalogue and booking process.

Yes. CRUISEC supports deep links that can direct customers to defined cruises, destinations, cruise lines, ships, dates or search results.

Yes. Deep links can be used in newsletters, social media, landing pages, banners and online campaigns.

CRUISEC can support search-engine-oriented website structures, content pages and landing pages. The final SEO result also depends on the customer’s domain, content strategy, technical setup and ongoing marketing activities.

Yes. CRUISEC may be integrated into an existing website. PAGEMAKER is recommended when the customer wants CRUISEHOST to provide a complete website and content-management environment.

Update frequency depends on the cruise line and data source. Catalogue data may be imported or refreshed regularly, while availability and final pricing are normally requested live.

This depends on the cruise line, market and price type. The price details shown during the booking process should indicate which components are included.

Yes, where they are included by the cruise line or configured as part of a package. The exact treatment depends on the product and market.

Depending on the cruise line and configuration, packages such as drinks, flights, transfers, hotels, insurance or other services can be displayed or added.

Individual calculations may be possible, including mark-ups, discounts, commissions, package values and customer-specific price rules.

Yes. Cruise-line promotions and customer-specific offers can be displayed where the required data is available.

Yes. Departure port is a standard search criterion in relevant CRUISEHOST search environments.

Yes. Depending on the search configuration, cruises can be filtered by ports of call and itinerary regions.

Yes. Search and filter options can include ship characteristics, onboard facilities, target groups and other attributes where the required content is available.

Yes. CRUISEC can be embedded in an existing website as an iframe when this is the selected implementation model.

Yes, when the responsive iframe setup and resizing communication are implemented correctly. The surrounding website must also be responsive.

The website owner must define a suitable iframe height and scrolling behaviour. A fixed height can create internal scrollbars or empty space on different pages and devices.

The host URL identifies the permitted parent page and can be used by the resizing and communication logic between CRUISEC and the surrounding website.

Yes. The iframe width can be adapted to the page layout, but a responsive width such as 100 percent is normally recommended for modern websites.

Yes. Depending on the project, CRUISEC can be used as a full-page solution, on a dedicated domain or subdomain, or through other supported integration methods.

Yes. Header and footer files hosted by the customer can be included where this integration method is supported and configured.

They should be available through secure HTTPS URLs, and referenced images, fonts, scripts and stylesheets should use absolute secure URLs.

No. They should contain only the required fragments and should not repeat the document type, html, head, body or unrelated metadata elements.

Yes. Device-specific stylesheets can be assigned where the implementation supports separate phone, tablet and desktop CSS.

Yes. The same stylesheet URL can be assigned to each device layout when one responsive CSS file is preferred.

External files may be cached. The project setup can include a cache-reset option so that updated files are loaded for testing.

Yes. The surrounding header, footer or page container can define the maximum width, provided the opening and closing markup remains valid.

Yes, when the selected template provides submenu placeholders and the corresponding menu configuration.

The available footer structure depends on the template. Traditional footer templates generally use a defined number of direct links rather than nested submenus.

Panel Admin is the CRUISEC administration tool used to place individual cruise offers or saved cruise searches prominently on CRUISEHOST landing pages.

Panels act as visual promotional elements that direct customers either to one specific cruise or to a result list based on predefined search criteria.

Log in to your CRUISEHOST account as an administrator, open the CRUISEC administration area and then go to Pages → Panel Admin.

There are two main methods:

1. Fixed cruise offer: a specific sailing identified by its MasterCruiseID and fixed departure date.
2. Dynamic search link: a saved CRUISEC search that opens a current result list matching defined criteria.

Both methods can be used at the same time within the same panel configuration.

A fixed cruise panel promotes one specific sailing with a fixed departure date. It is based on the cruise's MasterCruiseID.

When the customer clicks the panel, CRUISEC opens the offer page for that particular cruise.

A dynamic search panel uses a saved CRUISEC search link. When the customer clicks the panel, CRUISEC opens a result list based on criteria such as cruise line, destination, departure port or duration.

Choose a fixed panel when you want to promote one exact sailing, fare or campaign departure.

Choose a dynamic panel when the page should continuously show current results matching a broader theme, such as Mediterranean cruises, family cruises or departures from Hamburg.

Log in as an administrator, open CRUISEC and start a cruise search using the desired criteria. Click Offers to display the matching cruises.

In the CRUISEC search results, click the heart or reminder icon for every cruise you want to promote. The saved cruises are added to the Wishlist CruiseC Responsive.

The Wishlist CruiseC Responsive is the temporary collection of saved cruise offers and saved search links that can be transferred into Panel Admin.

It acts as the bridge between CRUISEC search and the panel configuration.

You should save at least as many cruise offers or search links as the selected panel layout contains display positions.

For example, a three-tile layout requires at least three saved entries, while a six-tile layout requires at least six.

A panel number identifies a specific collection of panel content. The number connects the entries managed in Panel Admin with the Panel Widget placed on a PAGEMAKER page or iframe design.

Go to Pages → Panel Admin. The saved entries appear in the Wishlist CruiseC Responsive. Assign the required panel number and click Take to panel.

After transferring the entries to Panel Admin, tick the checkbox in column A for the required panel and click Update.

A stands for activation. Tick the checkbox to activate the panel entry or remove the tick to deactivate it.

D is the delete option. Use it to remove a panel entry that is no longer needed.

P opens a preview of the panel in the available layouts. The panel must first be updated before the preview reflects the latest configuration.

A MasterCruiseID is the CRUISEHOST identifier for a specific cruise sailing. It is used when a panel should link directly to one defined cruise and departure date.

Yes. In the CRUISEC administration area, enter the required ID into the MasterCruiseID field. The entry is then saved to the wishlist and can be assigned to a panel number.

Open CRUISEC as an administrator and enter the required search criteria, such as destination, cruise line or duration. Click Offers and save the resulting search link.

A dynamic panel stores the search criteria rather than one sailing. Each click runs the search again and displays the currently available cruises that match those criteria.

Yes. Both methods can be used simultaneously. A panel can combine selected fixed sailings with dynamic search links, provided the selected layout has enough entries.

Show Period displays a travel period in the panel when the shown price is valid for different departure dates.

Activate the panel first and then tick Show Period for the relevant entry.

Use Show Period when a displayed price or promotion applies to several departures within a defined date range rather than to one single sailing.

The timestamp shows when the panel entry was last updated.

A panel should normally contain enough entries to fill the selected layout. Missing entries may produce an incomplete or visually unbalanced display.

Yes. The same cruise can be promoted in different panel numbers and on different landing pages when it is relevant to more than one campaign or theme.

Yes. A panel number can be reused on multiple suitable PAGEMAKER pages or layouts, depending on the website configuration.

Open the required page, select Add Widget and choose Panel. Select the panel type, assign the required panel number and save the page.

The schematic view helps you identify how each available panel type will be displayed.

The Panel Widget is the PAGEMAKER element that displays the panel content managed in Panel Admin. It connects a selected panel layout with a defined panel number.

Yes. Where the panel configuration supports customer images, Image Wizzzard provides secure and optimised image URLs for use in panel content.

Panels are designed to adapt to the available display width when used within a responsive CRUISEC or PAGEMAKER implementation. The final appearance also depends on the selected panel type and surrounding page design.

Yes. Where supported by the template and CSS CUSTOMIZER configuration, colours, typography, spacing and other visual details can be adapted to match the website design.

Panels add relevant, clickable cruise content to editorial landing pages. Dynamic panels are particularly useful because they can keep the bookable content current while the surrounding page contains unique, search-engine-oriented text.

Panels alone do not replace good SEO content. The page should also have meaningful headings, descriptions and internal links.

Dynamic panels work especially well on:

• Destination and region pages
• Cruise line pages
• Departure-port pages
• Family, luxury or expedition cruise pages
• Seasonal campaign pages
• Short cruise or long cruise pages
• Newsletter landing pages

Fixed panels are especially useful for:

• Flash sales
• Exclusive agency offers
• A selected departure with a strong price
• Limited-time promotions
• Featured packages
• A newly launched ship or itinerary

Yes, where the package is available within the configured CRUISEC catalogue and can be addressed through the relevant offer or search link. Panels can therefore promote customer-created packages alongside standard cruise products.

Panels are website marketing elements used to promote cruise content to all page visitors.

SmartOffer 360 is a personalised customer-offer presentation created for an individual customer from selected WatchList offers.

Fixed panels should be reviewed frequently because the promoted departure, price or availability may change. Dynamic panels require less maintenance, but their search criteria and page relevance should still be checked periodically.

Check the following:

• The panel contains enough entries for the selected layout.
• The correct panel number is assigned to the widget.
• The panel entries are activated in column A.
• You clicked Update after making changes.
• The saved search still returns matching cruises.
• The fixed cruise has not expired or become unavailable.

Click Update before opening the preview. The preview displays the last saved panel configuration.

1. Create the destination page in PAGEMAKER.
2. Add unique editorial content and SEO headings.
3. Create a CRUISEC search using the destination criteria.
4. Save the search link.
5. Transfer the link to a panel number in Panel Admin.
6. Activate and update the panel.
7. Add the Panel Widget to the PAGEMAKER page.
8. Use Image Wizzzard for suitable destination images.

1. Find the sailing in CRUISEC or enter its MasterCruiseID directly.
2. Save the sailing to the wishlist.
3. Assign it to the required panel number.
4. Click Take to panel.
5. Activate the panel entry and click Update.
6. Place the associated Panel Widget on the campaign page.
7. Remove or replace the entry when the campaign ends.

1. Create the package in CRUISECUSTOMIZER.
2. Upload and tag the campaign images in Image Wizzzard.
3. Make the package available in the required CRUISEC catalogue.
4. Create a fixed offer or suitable search link.
5. Transfer it to Panel Admin.
6. Add the panel to a dedicated PAGEMAKER campaign page.
7. Support the page with unique text and a clear call to action.

• Choose the correct fixed or dynamic method.
• Use enough entries for the selected layout.
• Check that every entry has a suitable title, image and price presentation.
• Verify the correct panel number.
• Activate all required entries.
• Click Update.
• Open the preview.
• Test every click destination.
• Check desktop, tablet and mobile display.
• Schedule a review date for fixed campaigns.

A UID is a customer-controlled identifier that can be added to a CRUISEC call so bookings made through that code can be identified.

The UID is separate from the Agency ID and can be used for partners, affiliates, branches, campaigns or other tracking purposes.

AID is the CRUISEHOST Agency ID under which the booking is created.

UID is an additional identifier supplied in the CRUISEC URL. It does not replace the AID and does not create a separate agency record.

No. The code is defined and controlled by the customer. CRUISEHOST does not know which company, person, branch or campaign is represented by an individual UID unless the customer maintains that information separately.

In Unlimited mode, UIDs do not need to be registered in CRUISEHOST before use.

The customer is responsible for ensuring that every UID follows the required syntax and is used consistently.

In Limited mode, the UID must be registered in the CRUISEHOST administration. CRUISEC validates the code used in the URL against the registered list.

Yes. Uppercase and lowercase characters are treated differently. For example, ExpertTours and experttours are different UID values.

Use only:

• Uppercase letters A-Z
• Lowercase letters a-z
• Numbers 0-9

Spaces and special characters should not be used because the UID is passed as part of a URL.

A UID can contain up to 13 characters.

1. Log in under the Agency ID that is licensed to use UIDs.
2. Open CRUISEC → CRUISEC_UID.
3. Enter the required UIDs.
4. Separate multiple UIDs with commas.
5. Save the list.

The administration also shows the number of registered UIDs.

Add the UID as a URL parameter after the AID:

https://server.cruisec.net/?aid=456456&uid=Test

• server.cruisec.net is the server allocated to the application.
• aid is the Agency ID licensed to use UID.
• uid is the case-sensitive partner or tracking code.

The booking is created under the AID Agency ID. The UID is stored as an additional identifier for the booking.

No. Because CRUISEHOST does not know who or what is represented by the UID, the UID itself does not provide booking access and does not automatically create an email recipient.

Yes. The UID value can be inserted into suitable email templates with the variable ##UID##.

For example: Thank you for your booking made through our partner ##UID##.

A UID is live as soon as it has been registered successfully.

CRUISEHOST takes a snapshot of the number of registered UIDs near the end of each month. That number is used for the following month's invoice according to the agreed UID price.

Example: if 23 UIDs are registered at the snapshot date in June, 23 UIDs are invoiced for July.

The exact snapshot date may vary.

• Using the wrong capitalisation
• Using spaces or special characters
• Exceeding 13 characters
• Using a UID that was not registered in Limited mode
• Using the UID with the wrong AID
• Forgetting the &uid= parameter in the URL

1. Define who or what each UID represents.
2. Use a consistent naming convention.
3. Choose Limited or Unlimited mode.
4. Register the codes where required.
5. Test the complete CRUISEC URL.
6. Verify the UID on a test booking or enquiry.
7. Define whether the UID should appear in customer emails.
8. Maintain an internal list of owners and active codes.
9. Remove unused Limited UIDs before the monthly snapshot.

CONFIG – Hide Cruises allows an agency to suppress selected cruise content before it appears in CRUISEC search results.

The function can be used to adapt the cruise database to the needs of a particular market, campaign or customer group and to focus result lists on the cruise lines, ships, ports and cruise areas that are commercially relevant.

Pre-filtering prevents irrelevant results from appearing in the first place. This can make result lists shorter, clearer and better aligned with the agency's market, portfolio and marketing objectives.

For example, an agency can suppress departure ports that are not normally used in its home market or temporarily focus a campaign on preferred cruise lines and ships.

Rules can be created for:

• Individual cruise lines
• Individual ships or all ships of a cruise line
• Departure ports
• Contained ports
• Arrival ports
• Cruise areas
• A defined validity period

Yes. A rule can apply to one cruise line and either selected ships or all ships belonging to that cruise line.

The rule can be limited to a defined start and end date.

Departure Port refers to the embarkation or entry port under which the cruise is offered in the search results.

This is especially useful when a sailing supports several possible entry ports but only some of them are relevant to the agency's market.

Contains Port hides every cruise whose itinerary contains the defined port.

The supplied specification states that multiple selections are not possible for this field, so a separate rule should be created for each contained port that must be excluded.

Arrival Port hides cruises whose defined final arrival or disembarkation port matches the port entered in the rule.

Yes. Cruise areas can be hidden for a selected cruise line, selected ships or all ships of that cruise line during a defined period.

For example, all AIDA cruises assigned to the Baltic Sea cruise area can be suppressed from the result list.

1. Open CONFIG – Hide Cruises.
2. Click Create Rule.
3. Enter a clear title for the rule.
4. Select the required cruise line and click Select.
5. Select individual ships or all ships.
6. Enter the period during which the rule should apply.
7. Define the relevant port or cruise-area condition.
8. Click Save.
9. Click Apply Rules.
10. Wait while the database is scanned in the background.

1. Click Create Rule.
2. Enter a title such as MSC MRS.
3. Select MSC as the cruise line.
4. Select the relevant ships or all MSC ships.
5. Enter the required validity period.
6. Enter MRS as the Departure Port.
7. Click Save.
8. Click Apply Rules.
9. Confirm the completion message with OK.

The rule suppresses the corresponding Marseille embarkation results for the selected MSC ships and period.

1. Create a new rule.
2. Enter a meaningful title.
3. Select AIDA as the cruise line.
4. Select all relevant AIDA ships.
5. Enter the validity period.
6. Select the Baltic Sea cruise area.
7. Click Save.
8. Click Apply Rules.
9. Confirm the completion message with OK.

Apply Rules starts the background scan that identifies all cruises matching the saved hide rules.

Saving the rule alone does not complete the process. The rules must be applied so the matching departures are identified and suppressed.

When the system has identified the matching cruises, a completion message appears. Click OK to return to the rules list.

Hidden Count shows how many departures were identified and hidden because of the rule.

Use this number as a plausibility check. An unexpectedly high or low count may indicate that the selected cruise line, ships, period or port condition should be reviewed.

Open the rules list and select Edit for the required rule. Change the title, cruise line, ships, period or filter condition and save the rule.

After editing, click Apply Rules again so the database is recalculated using the updated configuration.

A rule applies for the period defined in its configuration. This makes it possible to create temporary market, campaign or seasonal exclusions without permanently removing the underlying cruise content.

No. The function suppresses matching cruises from the relevant search results according to the configured rules. It does not delete the original cruise data from CRUISEHOST.

Check the following:

• The rule was saved.
• You clicked Apply Rules.
• The selected validity period includes the cruise date.
• The correct cruise line and ships were selected.
• The port code or cruise area is correct.
• The rule type matches the intended condition: Departure Port, Contains Port or Arrival Port.
• The background scan completed successfully.

A count of zero means that no departures matched the complete rule at the time it was applied.

Review the cruise line, ships, travel period, port code and cruise-area selection. The rule may be valid but simply have no matching departures in the current database.

• Use descriptive rule names.
• Keep the validity period as narrow as necessary.
• Prefer port-level exclusions when only one embarkation option is irrelevant.
• Check Hidden Count after every application.
• Test the affected CRUISEC search after applying rules.
• Document why each rule was created.
• Review active rules regularly.
• Remove or amend rules when market requirements change.

1. Define the business reason for the exclusion.
2. Choose the narrowest suitable rule type.
3. Select the cruise line and ships.
4. Set the validity period.
5. Enter the port or cruise-area condition.
6. Save the rule.
7. Apply all rules.
8. Confirm completion.
9. Check Hidden Count.
10. Run a customer-facing search to verify the result.
11. Record a review or expiry date.

CONFIG – Hide Ships is the assortment-control function used to decide which cruise lines and ships are available for selection in the customer-facing IBE.

Ships moved to the Hidden list are no longer offered as selectable assortment content.

The function allows an agency to actively define its cruise assortment. Cruise lines or ships that should not be sold or promoted can be removed from the selectable IBE portfolio.

Hide Ships controls whether ships or cruise lines belong to the selectable assortment in the IBE.

Hide Cruises applies more detailed suppression rules to cruise results based on cruise line, ship, period, departure port, contained port, arrival port or cruise area.

1. Open CONFIG – Hide Ships.
2. Select the required ship in the left-hand list.
3. Use the arrow button to move it to the right-hand Hidden list.
4. Repeat this for any additional ships.
5. Click Save.

Yes. Move every ship that should be excluded from the left-hand list into the right-hand Hidden list and then save the configuration.

Select the ship in the right-hand Hidden list and use the reverse arrow button to move it back to the available list. Then click Save.

Yes. Moving a ship between the two lists does not complete the change. Click Save so the new assortment configuration is stored.

Yes. The function is suitable for removing cruise lines or ships that are outside the agency's commercial focus, unavailable in its market or not intended for sale through the IBE.

Check the following:

• The ship appears in the right-hand Hidden list.
• You clicked Save after changing the list.
• You are testing the correct Agency ID and market.
• The browser or page is not showing an older cached result.

1. Review the cruise lines and ships in the current assortment.
2. Identify content that should not be selectable in the IBE.
3. Move the relevant ships into the Hidden list.
4. Click Save.
5. Open the customer-facing IBE and verify the assortment.
6. Document the reason for major portfolio exclusions.
7. Review the configuration regularly.

CONFIG – Price Promotion allows an agency to apply price increases or reductions to Cruise Only rates in the IBE.

It can also be used to create promotional cruise content by changing the cruise title and adding calculated values—such as onboard credit—to the title and included services.

The calculations apply only to Cruise Only products.

Packages are never processed by these calculations.

All settings in this area become active immediately after they are saved or changed.

More specific calculation types overwrite broader ones in the following order:

1. Default Surcharge – global rule for all Cruise Only rates
2. Volume Calculation – overwrites the default within a defined price range
3. Time Surcharge – overwrites Default and Volume rules for matching time-related parameters
4. Ship and Period Promotion – overwrites Default, Volume and Time rules for matching cruises

This is a global percentage surcharge or discount applied to all Cruise Only rates.

Enter the required percentage and click Change to save or update the setting.

Volume Calculation applies a percentage surcharge or discount to Cruise Only prices within a defined price range.

Within that range, the Volume Calculation overwrites the Default Surcharge. Multiple price ranges can be configured.

This calculation applies a percentage or fixed surcharge or discount to a ship within a defined time frame or a defined number of days before departure.

Cruise duration can be used as an additional parameter. Matching Time Surcharge rules overwrite Default Surcharge and Volume Calculation.

Multiple time-based parameter sets can be created.

This is the most specific promotion rule. It can select cruises using ship, sales period, days before departure, travel period and cruise duration.

It can either:

• adjust the actual Cruise Only price, or
• calculate a promotional value and place it into the cruise title and included services without changing the price.

The documentation describes the following selection options:

• Ship
• Sales month from and sales month to
• Alternatively, number of days before departure
• Travel period from and to
• Minimum and maximum cruise duration
• Percentage or fixed promotional value

A percentage value is calculated from the Cruise Only from-price.

A fixed value uses the entered amount directly.

The calculated result can either change the price or be used as a promotional value, depending on the Calc setting.

With Calc = Yes, the calculated surcharge or discount changes the price for all matching cruises.

The adjusted value continues to be applied after availability checking and during booking.

The customer sees and confirms the adjusted price. The agency booking email also identifies the uncalculated purchase price of the underlying cruise.

With Calc = No, the calculated value does not change the cruise price.

Instead, the following fields become available:

• Cruise Title
• B and A placement options
• Services Included

The calculated value can then be inserted into promotional text using the ##surcharge## variable.

B means the promotional text is placed before the original cruise title.

A means it is placed after the original cruise title.

Insert ##surcharge## wherever the calculated amount should appear.

Example cruise title:

Including onboard credit ##surcharge## –

Example included service:

We grant you onboard credit of EUR ##surcharge##, which will be transferred to you as a refund after the trip.

The system replaces the variable with the calculated value for each matching cruise.

For matching bookings, the promotional information can be provided in:

• The cruise title
• The included services
• The customer TPD or precontractual information
• The customer confirmation email
• The agency booking-information email
• The Backoffice XML file

Price Promotion can calculate a percentage or fixed amount for selected cruises and display it as onboard credit without changing the cruise price.

This is useful when a cruise line does not supply the marketing benefit in its data feed—for example, when onboard credit depends on cruise duration or booking category.

Yes. Customers with the required CRUISECUSTOMIZER licence can use their own cruise titles and included-services text to create differentiated content for matching Cruise Only products.

This can support unique website presentation and SEO differentiation where the underlying cruise-line feed does not contain the promotional wording.

Enter or adjust the relevant values and click Change to save the calculation.

Because the settings become active immediately, verify the result as soon as the rule has been changed.

Click Delete for the relevant existing rule.

After deletion, test a matching Cruise Only search to confirm that the rule no longer affects the result.

Check the following:

• The product is Cruise Only and not a package.
• The ship matches the rule.
• The sales period or days-before-departure range matches.
• The travel period matches.
• The cruise duration is within the configured range.
• The rule was saved with Change.
• A more specific rule is not overwriting the expected result.
• The correct Calc setting was selected.

• Document the purpose of every rule.
• Use the most specific parameters necessary.
• Avoid unintended overlapping rules.
• Check the overwrite hierarchy.
• Use Calc = No for benefits that should not alter the price.
• Use clear customer-facing wording.
• Test availability and booking behaviour.
• Check customer emails, agency emails and Backoffice XML.
• Remove expired promotions promptly.

1. Define whether the objective is a price change or a communicated benefit.
2. Confirm that the affected products are Cruise Only.
3. Select the correct calculation level.
4. Configure the ship, sales, travel and duration parameters.
5. Choose percentage or fixed value.
6. Select Calc = Yes or Calc = No.
7. For Calc = No, configure title placement and included-services text.
8. Save with Change.
9. Test matching and nonmatching cruises.
10. Check availability and booking output.
11. Verify TPD, emails and Backoffice XML.
12. Record an end date or deletion reminder for the campaign.

CONFIG – Recommendation allows an agency to highlight selected cruise lines in the cruise-line search selection used by CRUISEA and CRUISEC.

Preferred cruise lines are displayed at the top of the list under a customer-defined heading.

The selected cruise lines appear first in the Cruise Line search selection in both CRUISEA and CRUISEC.

1. Open CONFIG – Recommendation.
2. Tick the cruise lines you want to highlight.
3. Enter a heading for the highlighted group.
4. Click Save.

Yes. Enter a title such as Our Recommendations. The selected cruise lines will be grouped under that heading at the top of the search selection.

After the highlighted recommendations:

1. The remaining online cruise lines are listed under Top Partners.
2. The offline cruise lines are then listed under Other Shipping Companies.

Yes. Click Save after selecting the cruise lines and entering the heading.

Yes. Return to CONFIG – Recommendation, change the selected cruise lines or heading and save the configuration again.

No. Recommendation changes the order and grouping of the cruise-line selection. It does not remove the other cruise lines from the assortment.

Use CONFIG – Hide Ships or CONFIG – Hide Cruises when content should actually be excluded.

• Highlight only a manageable number of cruise lines.
• Use a meaningful heading.
• Align the recommendations with the agency's portfolio and commercial strategy.
• Review the list whenever preferred partnerships change.
• Test the order in both CRUISEA and CRUISEC.
• Do not use Recommendation as a substitute for assortment control.

1. Define which cruise lines should receive priority.
2. Choose a customer-facing group heading.
3. Select the preferred cruise lines.
4. Click Save.
5. Open the cruise-line search in CRUISEA.
6. Open the cruise-line search in CRUISEC.
7. Verify the highlighted group and the order of the remaining cruise lines.
8. Review the configuration regularly.

CRUISE-HUB is a host-agency and subagency management solution that supports the administration of travel agents, bookings, communication, commissions and related processes.

CRUISE-HUB is designed for host agencies, larger travel organisations, agency networks and companies managing bookings on behalf of multiple subagencies or independent travel agents.

Yes. Subagency and user structures can be created according to the host agency’s commercial and organisational model.

Yes. Subagencies can be provided with an appropriate CRUISEA, CRUISEAfree or CRUISEAlight account, depending on the agreed model.

Yes. Authorised host-agency users can access relevant bookings and booking-management functions according to their permissions.

Access rights can be configured so that subagencies see the information assigned to them, while the host agency retains the required overall access.

Yes. CRUISE-HUB can support commission calculations and different commission arrangements between the host agency and its subagencies.

Yes. Different commission levels and commercial arrangements can be configured, depending on the project and system setup.

Yes. CRUISE-HUB can include internal communication functions for booking-related messages between the host agency and the subagency.

Depending on the configuration, users can open or resend booking-related documents from the booking overview.

Cancellation functions may be available for eligible bookings. Cancellation is always subject to the cruise line’s rules, deadlines, fees and technical connection.

Payment-related information and actions may be available depending on the merchant model, cruise line and payment configuration.

CRUISEA provides the search, sales and booking environment, while CRUISE-HUB adds host-agency and subagency management processes around users, bookings, communication and commissions.

Yes. CRUISEA, CRUISE-HUB, CRUISEC and related tools can be combined to support host agencies and their subagency networks.

Yes. Individual accounts can be provided according to the host-agency agreement.

Depending on the configuration, documents, customer communications and websites can include subagency branding.

Yes. Payment and contractual processes can be configured so that the host agency acts as the responsible merchant or booking party, subject to legal and commercial requirements.

Yes. Commission rules can be configured according to the agreed host-agency model.

Yes. The workflow can be configured so that the host agency, subagency or both participate in customer communication.

Yes. A host agency may require subagencies to use the internal booking-related communication functions for operational communication.

Yes. Access can be deactivated according to the administrative process and contractual terms.

Billing depends on the agreed termination and invoicing rules. The effective date should be defined in the host-agency agreement.

PAGEMAKER is the CRUISEHOST page-building and content-management system for creating CRUISEC pages, landing pages and iframe layouts from reusable widgets.

Pages are assembled without fixed layout templates. Customers choose the required widgets, arrange them in the desired order and manage page variants independently.

No programming knowledge is required for normal page creation. Widgets can be added, configured and rearranged within the page editor.

HTML and CSS knowledge is helpful only for advanced customisation, external headers and footers, or custom HTML widgets.

• Full-page CRUISEC websites
• Responsive iframe layouts
• Landing pages
• Page and iframe variants
• Widgets and their order
• Publishing and scheduled activation
• Metadata, breadcrumbs and booking-level titles
• Header, footer and CSS URLs
• Menu items and subpages

Yes. HTML can be inserted where the relevant content widget supports it. This can be used for formatted text, tables, buttons, FAQ sections and compatible embedded elements.

Yes. Customers can create pages for destinations, cruise lines, ships, campaigns, departure ports, themes and package products.

Landing pages can combine editorial text, search, panels, sliders, product tables, contact forms and other widgets.

Yes. PAGEMAKER supports different CRUISEC search layouts, including a standard search, a search with a slider and a search placed over a slider background.

Yes. Authorised administrators can edit content, rearrange widgets, create variants, preview changes and publish pages without asking CRUISEHOST to make every content change.

CRUISEHOST supplies system content and standard product information where available. Customers can supplement or replace this with their own editorial content, images, panels, package content and campaign material.

When an iframe customer opens CRUISEC → PAGEMAKER, a standard CRUISEC iframe is provided. The customer can open its variants, edit the layout, publish it or delete an unused variant.

The standard iframe contains a cruise search and a panel designed to display up to six promoted offers.

If the panel is not populated, only the search is displayed.

The basic format is:

https://YYY.cruisec.net/?aid=XXXXXX

Replace YYY with the allocated server code and XXXXXX with the Agency ID.

Open the page or iframe in Edit mode and click Add Widget. Select the required widget, configure it and save the page.

Drag the required widget to its new position within the page structure. Newly created widgets can also be added from the content area.

• Save: saves changes to the current variant.
• Save As: creates another version or variant.
• Preview: displays the page before publication.
• Publish: makes the selected variant live.

Yes. One page can have several variants. This is useful for seasonal bestseller pages, campaigns and alternative layouts.

Yes. A date can be assigned so another page version becomes active automatically. This allows seasonal or campaign content to replace the current version without a manual change on the activation date.

Existing pages remain available and are marked as old. Individual content modules may still be editable, but the old page layout and structure cannot be changed directly.

1. Open PAGEMAKER and locate the old page.
2. Open Variants.
3. Click Edit on the published old variant.
4. Save the copied page.
5. Return to the variants list.
6. Edit and publish the new-format copy.

Yes. The original old page can still be published again, but its structure cannot be edited. Structural changes must be made in the copied new-format variant.

After the domain is linked to the CRUISEHOST agency, open PAGEMAKER and click New Page. Enter the page name, set Active to Yes and then add the required widgets.

The supplied documentation describes widgets including:

• Search
• Search with slider
• Search with slider background
• Content Split
• Panel
• Product Table
• Contact form
• Text and other content modules

Additional widgets may be added over time.

The Content Split widget provides layouts that divide a content area into separate visual sections. It can be used to combine different text, image or promotional elements within one row.

The Panel widget displays content prepared in Panel Admin. Select the panel type and assign the relevant panel number.

See the Panels and Panel Admin chapter for the complete setup workflow.

The Product Table widget creates a structured table of cruise products. It can be configured for a cruise area, cruise line or ship, with a selected travel period and duration filters.

The table can be positioned on the left or right, and the cruise-line logo is displayed alongside it by default.

1. Click Add Widget.
2. Select Contact.
3. Select Contact form.
4. Click New.
5. Load the default agency template if required.
6. Adjust the fields and wording.
7. Save the form and page.

When Show Advanced Settings is enabled, customers can configure:

• Page metadata
• Booking-level titles
• Breadcrumb names
• Unique links
• Header URL
• Footer URL
• CSS URL

Yes. A title can be assigned to each booking level. It can be displayed in the browser tab and as a breadcrumb on the page. Unique links can also be configured.

After storing a compatible Header and Footer URL, menu positions can be named and linked to pages. The number of available menu items and subitems is defined in the external header or footer HTML.

• Set Page: assigns one page directly to a menu item.
• Add Pages: assigns several pages as subpages or submenu items.

Pages are selected from the list of unassigned pages and confirmed after selection.

• Save the current changes.
• Open Preview.
• Test all search, panel and menu links.
• Check images and text.
• Test desktop, tablet and mobile widths.
• Submit the contact form if one is included.
• Verify the published variant and activation date.

The panel may be empty, inactive, assigned to the wrong panel number or not yet updated in Panel Admin. If the standard iframe panel contains no offers, only the search is displayed.

1. Define the page objective and target audience.
2. Create a new page or variant.
3. Enter the basic page settings.
4. Configure metadata and breadcrumbs.
5. Add and arrange the required widgets.
6. Populate panels and other linked content.
7. Save the page.
8. Preview and test all functions.
9. Check responsive display.
10. Publish immediately or schedule the required variant.

CSS CUSTOMIZER is a visual customisation tool for the standard CSS used by CRUISEHOST websites. It works with PAGEMAKER Widgets and the CRUISEC Booking Engine, helping customers create one integrated design across the complete web project without programming or template changes.

CSS CUSTOMIZER can be used to adjust visual elements such as:

• Fonts and font sizes
• Colours and backgrounds
• Hover states
• Opacity
• Buttons, links and spacing
• Search masks and filters
• Search-result design layouts
• Ship-detail design layouts
• PAGEMAKER Widgets
• CRUISEC Booking Engine elements
• Responsive presentation for desktop, tablet and mobile

CSS CUSTOMIZER is used within the CRUISEHOST website environment and applies styling consistently across PAGEMAKER Widgets and CRUISEC. This allows the website content and booking engine to follow the same design rules.

No programming knowledge is required for the standard CSS CUSTOMIZER functions. The tool is designed to let users change supported visual settings without manually programming CSS or modifying templates. As with any design change, the result should still be tested on the relevant page types and devices.

No. CSS CUSTOMIZER changes the visual presentation. It does not change the underlying cruise search, availability or booking functions of CRUISEC.

Yes. CRUISEHOST can provide the booking engine, website structure, PAGEMAKER CMS, design configuration, cruise content and technical implementation required for a complete cruise website.

Yes. Your logo and brand elements can be included in CRUISEA documents, CRUISEC, SmartOffer 360 and your PAGEMAKER website according to the selected configuration.

Yes. Branding can be adjusted through the standard configuration. More advanced visual changes can be applied through CSS CUSTOMIZER in PAGEMAKER.

Yes. A customer-owned domain or subdomain can be connected to the CRUISEHOST solution.

Domain ownership depends on the registration arrangement. Customers should ensure that important business domains are registered in their own name or that ownership and transfer rights are clearly documented.

Yes. Multi-brand, multi-market and white-label structures can be created, subject to the agreed licence and project design.

Yes. Host agencies and networks can provide branded or co-branded websites to subagencies using an agreed master configuration.

Yes. Customers are responsible for providing and approving their terms and conditions, privacy policy, legal notice and other required legal information.

No. CRUISEHOST can provide the technical areas in which legal texts are displayed, but customers should obtain legal advice from a qualified professional.

CSS CUSTOMIZER changes the visual presentation of PAGEMAKER and CRUISEC elements. CRUISECUSTOMIZER creates and manages packaged travel products and Travel Components.

Yes. It can control button backgrounds, text colours, borders, spacing and hover or focus states.

Yes. CSS CUSTOMIZER provides visual controls for supported search-result elements and also allows customers to choose from different SearchResult design layouts. Depending on the selected layout, typography, spacing, backgrounds, hover behaviour and other supported presentation settings can be adapted.

No. CSS changes appearance only. Functional changes require configuration, product development or another CRUISEHOST module.

Yes, when the font licence permits web use and the font files are supplied through secure, correctly referenced URLs.

Yes. Responsive media queries or separate device stylesheets can tailor the design for phone, tablet and desktop displays.

Yes. Broad selectors can override unrelated elements. CSS should therefore use project-specific classes and be tested on all important page types.

The standard CSS CUSTOMIZER functions are designed so that customers can make supported visual changes without programming knowledge. More complex project-specific CSS work can still be handled by an experienced web designer or provided by CRUISEHOST as an agreed service.

Yes, but the styles applied inside CRUISEC and those applied to the parent website remain separate unless both environments are configured.

Test search, details, booking steps, forms, error states and mobile layouts in current browsers before publishing the changes.

CRUISECUSTOMIZER is the highly modular CRUISEHOST packaging system. It allows customers to create their own cruise packages, combine cruises with additional travel components and publish unique bookable products for their market.

CRUISECUSTOMIZER enables travel companies to create content that competitors may not offer in the same form. Unique packages support product differentiation, improve SEO opportunities and allow the seller to create an attractive complete price for the customer.

CRUISECUSTOMIZER supports several package models:

• Type 1 – Simple Offer: a straightforward package or offer based on defined content and pricing.
• Type 2 – Allotment: packages based on a fixed allotment of cabins or other reserved inventory.
• Type 3 – Dynamic: packages created dynamically from live or currently available components.
• Type 4 – Special Fares Dynamic: dynamic packages using special cruise fares or specifically configured pricing.
• Type 5 – Master Allotment and Subpackages: several package flavours can book into the same underlying allotment.

A Type 1 package is a simple offer containing the cruise and the services or pricing defined by the customer. It is suitable when no complex allotment or dynamic package logic is required.

A Type 2 package uses reserved inventory, such as a defined cabin allotment. The package can be sold against this inventory according to the configured availability, prices and sales rules.

A Type 3 package combines the cruise and other services dynamically. Availability and prices can be assembled from the connected components when the customer searches or books.

A Type 4 package uses dynamic packaging together with special cruise fares or specially configured rates. This allows the package seller to create differentiated products and pricing based on the available commercial agreements.

A Type 5 package uses one master allotment as the common inventory source for several subpackages. Different package flavours can therefore be offered while all of them book into the same underlying allotment.

Subpackages are alternative versions of the same core product. For example, one package may include the cruise and a beverage package, another may include the cruise and flights, and another may include the cruise, beverage package and flights. All of these flavours can book into the same master allotment.

Travel Components are individual services that can be combined with a cruise to create a package. Examples include flights, transfers, hotel nights, beverage packages, insurance or other pre-cruise and post-cruise services.

Yes. Individual Travel Components can be assembled into a reusable pre-cruise or post-cruise package and then connected to suitable cruises.

A travel agent could create a package consisting of a flight to Miami, a transfer from the airport to the hotel, one pre-cruise hotel night, a transfer from the hotel to the ship, and after the cruise a transfer to the airport and the return flight.

Yes. A reusable pre-cruise package can be “married” with all suitable cruises, for example all cruises departing from Miami. This avoids rebuilding the same travel components for every individual sailing.

Yes. Customers can combine their own packages, negotiated services, components and pricing with cruise content to create products that are unique to their business and target market.

Unique package combinations create original product and landing-page content instead of displaying only the same standard cruise offer available on many other websites. This gives customers additional opportunities to build destination, departure-port, package and campaign pages that are relevant for search engines.

Yes. By combining contracted or selected travel components with the cruise, customers can create a complete package with its own calculated selling price. The available pricing options depend on the package type, component costs, allotments and commercial configuration.

Yes. The system is highly modular. Customers can use only the package types and Travel Components required for their business model and expand the setup as their product strategy develops.

Yes. A package can combine services before and after the cruise, such as flights, hotels, transfers, rail, excursions or other Travel Components.

Yes. Reusable Travel Components reduce repeated data entry and allow standard services to be combined with many suitable cruises.

Yes. A reusable component chain such as flight, airport transfer, hotel night and transfer to the ship can be associated with all matching cruises departing from Miami, subject to dates, capacity and pricing rules.

Yes. The package can include transfer from the ship to the airport and the return flight, together with any additional post-cruise services.

A package flavour is a variation of the same underlying product, for example cruise only, cruise with beverage package, cruise with flights, or cruise with flights and beverage package.

Yes. Subpackages can sell against one master allotment so that different product variants draw from the same controlled inventory.

It prevents inventory from being divided unnecessarily between package variants and gives the customer one central place to control the available capacity.

Yes. Package calculations can include component costs, mark-ups, discounts, margins and other agreed commercial rules.

Yes. Package Type 4 is designed for dynamic packages that use defined special fares where the required fare and booking conditions are available.

Yes. Unique package names, descriptions, included services, destinations and prices can support differentiated landing pages and search-engine content.

Yes. Components can be controlled by travel dates, booking dates, departure points, destinations, capacity and other applicability rules.

Depending on the package setup, a component can form part of the fixed package or be offered as an optional addition.

Yes. A package can combine services from different suppliers when the customer has the necessary contracts, prices and operational processes.

Yes. Packages can be configured for specific markets, currencies, languages, departure airports, commercial rules and customer catalogues.

Where packages reference a reusable component, a controlled update can be applied centrally, subject to versioning and existing booking rules.

The CRUISE-API allows external websites, applications and technology platforms to access CRUISEHOST cruise content and booking functions programmatically.

The CRUISE-API is suitable for:

• Online travel agencies
• Tour operators
• Travel technology companies
• Large travel agency groups
• Airlines
• Loyalty programmes
• Media and affiliate platforms
• Companies developing their own booking engines
• AI-supported travel applications

Depending on the selected API version and licence, data may include:

• Cruise lines
• Ships
• Itineraries
• Ports
• Destinations
• Departure dates
• Durations
• Cabin categories
• Prices
• Availability
• Ship information
• Images
• Descriptions
• Included services
• Booking conditions
• Customer-specific packages

Yes. For supported cruise lines, the API can request live availability and current prices from connected cruise-line systems.

Yes. Depending on the API version, cruise line, licence and certification status, bookings can be created through the API.

A softbooking records the booking request within the CRUISEHOST environment without creating a confirmed booking in the cruise line’s reservation system. It can be used for testing, enquiry workflows or cruise lines without a full live booking connection.

Yes. A test account can be provided. Test environments may use dummy cruise-line access, live-style availability requests and softbookings that are not transmitted as confirmed bookings to the cruise line.

Depending on the test configuration, softbookings can be viewed in the CRUISEA booking area.

A CRUISEAfree account may be used as the contractual and administrative basis for an API test account. The required API access can then be added to the account.

No. Every API customer can have a dedicated catalogue with individual cruise lines, markets, prices, languages, packages, calculations and commercial rules.

The permitted storage, caching and use of data depends on the API agreement, cruise-line rules and data licence. API customers must comply with the agreed technical and contractual restrictions.

Not without explicit written permission. Cruise catalogue, availability, pricing and customer-specific data may only be used for the agreed purpose. It must not be transferred to third-party AI services, used for model training or retained outside the authorised environment unless this has been expressly approved.

This depends on the commercial model. In many cases, each customer requires a dedicated catalogue because prices, markets, languages, packages and cruise-line access can differ.

Yes. Technical documentation and access credentials are provided as part of the API onboarding and test process.

Yes. Our project and technical teams support the integration process, answer implementation questions and coordinate testing.

Confidentiality and data-use requirements must be contractually secured. Depending on the commercial relationship, these obligations may be covered by the customer agreement or by a separate non-disclosure agreement.

Yes, if authorised by the customer and if the developer is contractually bound by the required confidentiality, security and data-use obligations.

No. Secret credentials should remain on a secure server and must not be exposed in public client-side code.

Yes. Production and test integrations should use secure HTTPS endpoints.

Tokens should be stored only as long as necessary, protected from unauthorised access and handled according to the agreed security design.

Use controlled retries with increasing delays for retryable errors, while avoiding duplicate bookings or excessive requests.

Use stable transaction references, idempotent workflow controls where available and a final status check before repeating a booking request.

Catalogue search data may be cached within the permitted rules, but current cabin availability and final prices should be confirmed through the live interface.

Yes. Each customer can receive a dedicated catalogue, market, language, currency, pricing and package configuration.

Log the timestamp, environment, endpoint, agency, transaction reference, response status and a sanitised error message without exposing passwords or personal data.

Only the minimum required data should be logged, and logs must be protected and retained according to the applicable data-protection and security rules.

Before production use, the agreed search, availability, option, booking, error and cancellation workflows must be tested and approved by CRUISEHOST. Certification and formal CRUISEHOST sign-off are mandatory before go-live. CRUISEHOST requires at least one week's notice to schedule certification and performs the tests independently. Standard API developments must also pass the full CRUISEHOST certification criteria. See KB-API-027A for the complete criteria and KB-API-027C for the certification process.

Before a standard CRUISEHOST API development is approved for production, the complete integration must be tested against the following certification criteria. These criteria apply to normal development without AI or LLM integration.

1. API Integration Testing

• Ensure that the website integrates seamlessly with the CRUISEHOST API endpoints.
• Test each API endpoint to verify that it returns the expected data in the correct format.
• Check for proper handling of authentication and authorization mechanisms.

2. Data Accuracy and Consistency

• Validate that the data displayed on the website matches the data fetched from the CRUISEHOST API.
• Verify that the website accurately represents the information provided by the API without discrepancies or data loss.

3. Error Handling

• Test error scenarios by intentionally providing incorrect input or triggering error conditions.
• Verify that error messages returned by the API are displayed appropriately on the website and provide meaningful information to the user.

4. Performance Testing

• Assess the website's performance under normal and peak load conditions.
• Measure response times for API requests to ensure they meet acceptable performance standards.
• Check for latency issues or bottlenecks that may impact the user experience.

5. Security Checks

• Review the website's implementation of authentication and authorization mechanisms.
• Verify that sensitive data transmitted between the website and the CRUISEHOST API is encrypted and securely handled.
• Check for vulnerabilities such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF).

6. User Experience (UX) Testing

• Evaluate the usability and intuitiveness of the website interface.
• Ensure that users can navigate through the website easily and perform actions without encountering errors or confusion.
• Test the responsiveness of the website across different devices and screen sizes.

7. Compatibility Testing

• Test the website on various browsers, including Chrome, Firefox, Safari and Edge.
• Check compatibility with different operating systems, including Windows, macOS, iOS and Android.
• Verify that the website functions correctly on both desktop and mobile devices.

8. Cross-Browser Compatibility

• Test the website's appearance and functionality across different web browsers.
• Ensure that layout, styling and interactive elements are consistent and work as expected on each browser.

9. Accessibility Testing

• Evaluate the website's accessibility for users with disabilities.
• Ensure that the website complies with applicable accessibility standards such as WCAG and is usable by people with visual, auditory, motor or cognitive impairments.

10. Content Verification

• Review the content displayed on the website to ensure accuracy and relevance.
• Check for broken links, missing images and other content-related issues.

11. Compliance Testing

• Ensure that the website complies with relevant regulations and standards, for example GDPR or HIPAA where applicable.
• Verify that the website's privacy policy, terms of service and other required legal documents are displayed and accessible to users.

12. CRUISEHOST Guidelines for Integration

• The integration must not contain an OFFLINE Request Form that bypasses CRUISEHOST / HOST AGENT.
• Scraping departures for data extraction is strictly prohibited.
• The integration must send the correct emails to customers after a request is generated. CRUISEHOST does not send these customer emails.
• Displayed pricing must be correct and match the data supplied by CRUISEHOST.
• It is strictly prohibited to use the CRUISEHOST API in any architecture in which CRUISEHOST API data is processed by LLMs or AI systems.

Important: This article describes the certification criteria for a conventional API implementation without AI. Any proposed AI-enabled architecture requires separate CRUISEHOST review and certification under KB-API-027B before CRUISEHOST API data may be processed by LLMs or AI systems.

AI-enabled integrations require a separate and substantially stricter certification process. The AI architecture must be disclosed to CRUISEHOST and must demonstrate controlled data lifecycle, isolation, deletion, model behaviour, output safeguards, auditability and ongoing governance.

Important: AI inclusion is not covered by the standard API certification in KB-API-027A. The following AI-specific criteria apply in addition to the normal technical certification requirements.

CERTIFICAION CRITERIA

 

1. Data Lifefycle, Persistence & Deletion

1.1 Prohibition of Training & Model Adaption:
Requirement
CRUISEHOST data must not be used for:

• pre-training

• fine-tuning

• reinforcement learning

• feedback-based optimization

• model evaluation datasets.

This applies to:
 

• raw data

• transformed data

• summarized or anonymized data

• embeddings or vector representations

Interpretation: If CRUISEHOST data influences future model behaviour, directly or indirectly, this requirement is violated.

Allowed: transient inference
Forbidden: anything that changes weights, memory, ranking, scoring, or response distribution

 

1.2 Transient Processing only (No Persistent Storage by Default)
Requirement
CRUISEHOST data my only be processed in a transient, session-bound context.

Persistent storage is prohibited unless:

• explicitly approved by CRUISEHOST, and

• strictly limited in scope and duration, and

• technically isolatable and deletable

This includes:

• databases

• object storage

• vector databases

• cache layers

• logging systems

• monitoring / telemetry systems

1.3 Vector Databases & Embeddings (Explicit Handling)
Requirement
If CRUISEHOST data is transformed into embeddings or vector representations:

• embeddings must be stored in a dedicated namespace / index / tenant

• no co-mingling with data from other providers or customers is allowed

• retention time must be explicitly defined (max. TTL)

• automatic deletion mechanism must be in place

Hard restriction

• CRUISEHOST embeddings must not exist in shared or global vector indices

• Re-indexing or re-use after deletion is prohibited.

1.4 Comprehensive Deletion Obligation ("Right to Obliterate")
Requirement
Upon request, the AI partner must irreversebly delete all CRUISEHOST-related data, including but not limited to:

• raw API responses

• derived datasets

• embeddings /vector indices

• prompt logs

• conversation histories

• backups where feasible

• monitoring & telemetry data

Deletion must be:

• selective (CRUISEHOST-only)

• technically enforced (not manual)

• completed within a defined timeframe (e.g. 30 days)

1.5 Proof & Auditability of Deletion
Requirement
The AI partner must be able to demonstrate:

• the technical mechanism used for deletion

• which systems are affected

• how deletion is verified

At minimum this includes:

• a written deletion procedure

• an architectural diagram showing data locations

• a deletion confrmation report upon request

CRUISEHOST resevers the right to:

• request ad-hoc deletion

• request formal confirmation

• suspend API access until confirmation is provided

Things to add:
1) How do you support context, memory, analytics, debugging, or quality monitoring? (if data is not stored permanently)
2) Sub-processors must adhere to the same deletion and non-training obligation. (if "our model provider stores prompt logs, but only for safety")
3 ) You cannot store the data at all (if "we can't selectively delete embeddings")

 

2. Architecture, Data Isolation & System Boundaries
2.1 Mandatory Architecture Disclosure
Requirement:
The AI partner must provide a high-level system architecture diagram covering:

• API ingestion points
• preprocessing / transformation layers
• AI components (LLM, RAG, orchestration)
• storage layers (DBs, vector stores, logs)
• third-party services and model providers

The diagram must clearly indicate:

• where CRUISEHOST data enters the system
• where is is processed
• where it may be stored
• where deletion occurs

2.2 Logical and Phsyical Data Isolation
Requirement
CRUISEHOST data must be isolated at at least one of the following levels:

• tenant-level isolation
• namespace / index-level isolation
• dedicated storage resources (preferred)

Isolation must apply to:

• databases
• caches
• vector stores
• message queues
• logging systems

2.3 No Cross-Provider Knowledge Contamination
Requirement
CRUISEHOST data must not be combined with:

• other travel providers' proprietary data
• scraped or unofficial cruise-related sources
• manually uploaded datasets of unclear provenance

This includes indirect combination via:

• merged embeddings
• aggregated summaries
• learned ranking or scoring layers

If multiple data sources are used:
CRUISEHOST data must remain identifiable, separable, and removable

2.4 API oundary Enforcement
Requirement
CRUISEHOST data may only be accessed via:

• officially issued API credentials
• approved domains and environments
• documented endpoints and flows

Prohibited:

• offline dumps
• bulk exports
• replaying stored responses beyond their lifecycle
• scraping or reconstruction via AI prompts

2.5 Separation of AI Logic and Booking Logic
Requirement
AI components must not:

• execute bookings directly
• bypass CRUISEHOST booking flows
• generate bookings programmatically without explicit confirmation

The system must enforce a clear separation between:

• advisory / conversational AI logic
• transactional booking logic

This separation must be visible in the architecture

2.6 Kill-Switch & Dependency Control
Requirement
The AI integration must support an immediate shutdown of CRUISEHOST data usage by:

• deactivating API credentials, or
• disabling CRUISEHOST-specific modules

After shutdown:

• no CRUISEHOST data may be accessible
• no cached or derived data may continue to power AI responses

If the AI system degrades gracefully but continues functioning, it must do so without referencing CRUISEHOST content.

Verlangen: Annotated Architecture Diagram + Data Isolation Statement + Environment Declaration

 

3. Model Behaviour, Outputs & Hallucination Control

 

3.1 Advisory Attribution

Requirement

All advisory, comparative, or evaluative AI output must be clearly attributed to the AI system or its operator, not to CRUISEHOST.

This includes:

• recommendations

• rankings

• “best for you” suggestions

• price/value assessments

• suitability judgments

Mandatory

• explicit wording indicating AI-generated advice

• clear separation between:

  • CRUISEHOST data (facts)

  • AI interpretation (opinions)

Forbidden

• wording suggesting endorsement by CRUISEHOST

• “based on CRUISEHOST recommendation…”

• “CRUISEHOST suggests…”

3.2 Visual & Linguistic Separation

Requirement

The user interface must clearly distinguish:

• CRUISEHOST factual data

• AI-generated advisory content

This can be achieved by:

• UI separation (boxes, labels, colors)

• explicit phrasing (“AI Insight”, “AI Opinion”)

• disclaimers placed close to the output (not hidden)

Insufficient

• footer disclaimers

• generic “AI-generated content” notes

3.3 Advisory Scope Limitation

Requirement

AI advice must be:

• contextual

• non-binding

• explainable

Forbidden advisory patterns

• absolute statements (“this is the best choice”)

• guarantees (“this will be cheaper”, “always recommended”)

• implied insider knowledge (“cruise lines usually do X”)

Required

• explanatory framing (“based on your preferences…, the AI considers…”)

• optionality (“one possible option is…”)

3.4 Data Boundary Enforcement in Advisory Reasoning

Requirement

AI advisory logic must not:

• infer hidden rules of CRUISEHOST pricing

• extrapolate trends from limited data

• imply access to non-exposed CRUISEHOST logic (“internal data shows…”)

The AI may:

• reason based on visible attributes

• explain differences based on factual data

The AI may not:

• invent causal relationships tied to CRUISEHOST systems

3.5 Advisory Accountability Statement

Requirement

The AI provider must contractually accept that:

• advisory output is their responsibility

• CRUISEHOST acts solely as a data provider

• CRUISEHOST assumes no liability for advice quality or outcomes

 

3.6 Output Scope Limitation (Anti Data-Extraction)
Requirement
The AI must prevent bulk extraction of CRUISEHOST data via conversational prompts, e.g.:

• "List all cruises departing from..."
• "Give me a table of prices for the next 12 months"
• "Export all itineraries for..."

3.7 User Perception Safeguards
Requirement
The AI interface must make clear that:

• it is not CRUISEHOST
• it does not act on behalf of CRUISEHOST
• CRUISEHOST is a data provider, not the advisor

This may include:

• disclaimers
• visual separation
• wording guidelines

4. Compliance, Auditability & Ongoing Governance
 

4.1 AI Self-Disclosure Obligation

Requirement

Before certification, the AI partner must submit a written AI Self-Disclosure including:

• description of AI use cases (advisory scope)

• models used (incl. third-party providers)

• data sources used for advisory reasoning

• confirmation of compliance with all AI Certification Categories

This disclosure must be:

• truthful

• complete

• updated upon material changes

False or misleading disclosures result in immediate suspension.

4.2 Sub-Processor Transparency & Flow-Down Obligations

Requirement

The AI partner must disclose:

• all sub-processors involved in AI inference, storage, or logging

• hosting locations (regions)

• model providers (e.g. OpenAI, Anthropic, Azure, GCP, etc.)

Hard rule

All CRUISEHOST obligations apply fully to sub-processors.

No “model provider exception”.
No “we can’t influence that”.

If they can’t control a sub-processor → they can’t use CRUISEHOST data.

4.3 Audit & Verification Rights

Requirement

CRUISEHOST reserves the right to:

• request additional documentation

• request clarification of AI behaviour

• demand deletion confirmation

• suspend API access pending clarification

Audit scope includes:

• data handling

• deletion mechanisms

• advisory attribution

• API usage patterns

Important

Audit rights do not require proof of breach – suspicion is sufficient.

That alone changes behaviour.

4.4 Change Management & Re-Certification

Requirement

The AI partner must notify CRUISEHOST prior to:

• introducing new models

• changing advisory scope

• altering data storage mechanisms

• enabling agentic or autonomous patterns

• expanding CRUISEHOST data usage

Such changes may require:

• partial re-certification

• full re-certification

• temporary suspension

“No material change” must be defensible, not asserted.

4.5 Incident Response & Breach Handling

Requirement

The AI partner must have:

• a documented incident response process

• a notification obligation towards CRUISEHOST

Notification required if:

• CRUISEHOST data is exposed or misused

• segregation rules are violated

• AI output falsely implies CRUISEHOST endorsement

• abusive usage patterns are detected

Maximum notification latency

• 72h legal upper bound

• operational expectation: as soon as detected

4.6 Explicit Liability Separation

Requirement

Contracts must clearly state:

• CRUISEHOST is a data provider only

• advisory output is generated by the AI partner

• CRUISEHOST assumes no responsibility for advice quality, suitability, or outcomes

This applies especially to:

• recommendations

• comparisons

• “best for you” logic

If wording is ambiguous, certification fails.

Any partner developing its own application using the CRUISEHOST CRUISE-API must complete a mandatory CRUISEHOST certification before the application may go live.

Do not launch before formal approval: The development may only go live after CRUISEHOST has formally approved and signed off the implementation. Going live without this approval may result in immediate suspension of the API account.

Scheduling and execution

• CRUISEHOST requires at least one week's notice to schedule the certification.
• Certification tests are performed independently by CRUISEHOST; the partner does not actively participate in the testing.
• If questions, issues or errors are identified, CRUISEHOST will contact the partner by email.
• The partner must correct the findings promptly, after which CRUISEHOST will resume and complete certification.

API usage and architecture

If a partner is unsure how the API should best be integrated, it should provide a system diagram showing how CRUISEHOST data is ingested and where live API calls will be performed. CRUISEHOST can then review the setup and advise on best-practice API usage.

Data caching and Catalogue JSON

• Avoid caching CRUISEHOST LIVE API data, except for short-lived session caching.
• If Catalogue JSON data is available, do not refresh catalogue content using live API calls.
• The Catalogue JSON may be downloaded up to four times per day.

Look-to-book ratio and efficient API usage

Every non-booking API call increases the look-to-book ratio, which can increase API fees. Efficient API usage is therefore in the partner's own financial interest.

Mandatory domain declaration

Before go-live, the partner must confirm all domains on which CRUISEHOST content and the CRUISE-API will be used or displayed.

Related criteria: Conventional implementations must meet KB-API-027A. AI-enabled implementations must additionally meet KB-API-027B.

Normally no. Dedicated credentials and customer catalogues help preserve security, reporting and commercial separation.

Material interface changes should be documented through the current technical documentation, release information and direct project communication where required.

The current API documentation, credentials, project agreement and written technical clarifications are authoritative.

Yes, for understanding concepts and legacy workflows, but they should not be copied into a new production integration without verification.

CUST_EMAILS_AGT is the CRUISEHOST administration area for customer-facing email templates that are sent automatically after a customer request or related business transaction.

The templates can be adapted to the agency's wording and can use email-specific variables populated from agency, request, cruise, traveller and payment data.

When a customer makes a request through the agency website, CRUISEHOST automatically sends a confirmation email to the customer.

CRUISEHOST distinguishes between different business transactions triggered by the customer request.

The transaction type depends on the cruise line and its technical connection to CRUISEHOST. Separate templates make it possible to use wording that matches the actual request or booking process.

1. Open EMAILS – CUST_EMAILS_AGT.
2. Locate the required business-transaction template.
3. Click Edit.
4. Adjust the existing email text.
5. Keep or insert the required variables.
6. Save the template.
7. Test it with a suitable customer request.

Email variables are placeholders written in the format ##variable##. When the email is generated, CRUISEHOST replaces each supported placeholder with the corresponding data from the agency or customer request.

These variables are documented specifically for CUST_EMAILS_AGT and should not be assumed to work in other CRUISEHOST modules.

Variable	Description
##mgw_name1##	Agency name or primary agency-name field

Variable	Description
##name##	Customer name or request name, depending on the template context
##datetime##	Date and time of the request or transaction
##id##	Request or transaction ID
##agb_file##	Terms-and-conditions file or related reference
##buchung##	Booking or transaction information

Variable	Description
##katalog_code##	Catalogue or product code
##reisedatum##	Travel or departure date
##dauer##	Cruise duration
##cruisename##	Cruise or itinerary name
##schiff##	Ship name
##reederei##	Cruise line

Variable	Cabin type
##st_2bett_innen_bez##	Two-berth interior cabin description
##st_2bett_aussen_bez##	Two-berth oceanview cabin description
##bk_2bett_aussen_bez##	Two-berth balcony cabin description
##ms_2bett_aussen_bez##	Two-berth mini-suite description
##s_2bett_aussen_bez##	Two-berth suite description

Variable	Description
##special_notes##	Special notes associated with the request or product
##add_eing_leistungen_memo##	Additional or included-services memo
##cruiselink##	Link to the cruise or relevant cruise page

Variable	Description
##angebot_anreise##	Travel-component or arrival offer
##abfahrt_abflug_von##	Departure or flight origin
##anreise_cur##	Currency of the travel component
##anreise_grs_to_pax##	Travel-component price or amount allocated to passengers
##anreise_text##	Travel-component description

Additional services are organised into numbered groups. Each group can contain a title, description, currency and price or passenger amount.

The supported groups in the supplied documentation are numbered 2 through 5.

Service group	Title	Description	Currency	Price/amount
2	##title_2##	##weitere_leistungen_2##	##mgw_affiliate_currency_code##	##wl_grs_to_pax_2##
3	##title_3##	##weitere_leistungen_3##	##mgw_affiliate_currency_code##	##wl_grs_to_pax_3##
4	##title_4##	##weitere_leistungen_4##	##mgw_affiliate_currency_code##	##wl_grs_to_pax_4##
5	##title_5##	##weitere_leistungen_5##	##mgw_affiliate_currency_code##	##wl_grs_to_pax_5##

Traveller	Surname	First name	Date of birth	Gender
Adult 1	##erw_1_name##	##erw_1_vorname##	##erw_1_geb##	##erw_1_gesch##
Adult 2	##erw_2_name##	##erw_2_vorname##	##erw_2_geb##	##erw_2_gesch##
Adult 3	##erw_3_name##	##erw_3_vorname##	##erw_3_geb##	##erw_3_gesch##
Adult 4	##erw_4_name##	##erw_4_vorname##	##erw_4_geb##	##erw_4_gesch##

Traveller	Surname	First name	Age	Date of birth	Gender
Child 1	##kind_1_name##	##kind_1_vorname##	##kind_1_alter##	##kind_1_geb##	##kind_1_gesch##
Child 2	##kind_2_name##	##kind_2_vorname##	##kind_2_alter##	##kind_2_geb##	##kind_2_gesch##
Child 3	##kind_3_name##	##kind_3_vorname##	##kind_3_alter##	##kind_3_geb##	##kind_3_gesch##

Variable	Description
##name##	Customer surname or name
##vorname##	Customer first name
##strasse##	Street address
##plz##	Postal code
##plz_ort##	City or postal-code location field
##telefon_gesch##	Business telephone number
##telefon_priv##	Private telephone number
##fax##	Fax number
##email##	Customer email address

Variable	Description
##zahlungsart##	Selected payment method
##mgw_affiliate_currency_code##	Agency or transaction currency code
##cc_geb##	Payment or credit-card fee

A typical payment-fee line can be written as:

+ ##mgw_affiliate_currency_code## ##cc_geb##

Variable	Description
##mitteilung##	Message entered by the customer during the request

A variable can remain empty when the corresponding information was not supplied, does not apply to the transaction or is not available from the cruise line or booking process.

For example, traveller 4 variables will not contain data when only two travellers were entered.

They should be treated as email-template variables only. Their documentation in this chapter does not mean they are available in PAGEMAKER, APIs, Backoffice XML or other CRUISEHOST modules.

Other modules have their own fields, placeholders or data structures.

• Use a clear subject and opening sentence.
• Keep the agency name and contact details visible.
• Use only variables valid for CUST_EMAILS_AGT.
• Do not change the spelling of placeholders.
• Structure long information into short paragraphs or tables.
• Account for optional variables that may be empty.
• Avoid exposing internal-only codes without explanation.
• Test each business-transaction template separately.
• Check desktop and mobile email rendering.

1. Edit and save the required business-transaction template.
2. Create a test request that triggers that transaction.
3. Use a test email address you can access.
4. Check that the correct template was selected.
5. Verify every populated variable.
6. Check how empty optional values are displayed.
7. Test all links and attachments.
8. Review the email on desktop and mobile.

• Removing one or more # characters from a variable
• Adding spaces inside a variable name
• Using a variable from another CRUISEHOST module
• Expecting optional data to always be present
• Using invalid or incomplete HTML
• Editing the wrong business-transaction template
• Failing to test links, PDFs or terms-and-conditions references

1. Identify the business transaction that needs new wording.
2. Open the corresponding template with Edit.
3. Review the existing variables before changing the text.
4. Insert only documented email variables.
5. Save the template.
6. Create a matching test request.
7. Verify the selected template, variables, links and attachments.
8. Correct any empty or awkward sections.
9. Retest the final version.
10. Document major template changes internally.

CRUISEHOST provides access to a broad international portfolio of ocean, expedition, luxury and river cruise lines. The exact portfolio depends on the customer’s market, contracts, licence and technical configuration.

No. Cruise-line connections can differ. Some cruise lines provide full live search and booking interfaces, while others may provide availability only, catalogue content, request-based bookings or softbooking processes.

A live booking connection allows CRUISEHOST to communicate directly with the cruise line’s reservation system to request current prices, cabin availability and, where supported, create an option or confirmed booking.

A dummy connection simulates the cruise-line booking process for testing. It allows developers and users to test availability and booking workflows without creating a real booking in the cruise line’s system.

Catalogue data describes the cruise product, such as the itinerary, ship, departure date and indicative prices. Live data is requested from the cruise line and confirms current availability, cabin categories and final prices.

Yes. Cruise prices and availability can change at any time. The final price is confirmed during the live availability or booking request.

The cruise may have sold out, the selected cabin category may no longer be available, the cruise line may have changed the price or the availability request may have been rejected. Cruise inventory changes continuously.

Yes. Cruise lines may provide different prices, promotions, currencies, booking conditions and product access for different markets.

Yes. Cruise-line access can be configured according to the relevant market and customer agreement.

Yes. The visible and bookable cruise-line portfolio can be adapted according to your business requirements and contracts.

Customer-specific rates, packages and commercial rules may be integrated where the cruise line, data source and technical setup support them.

PAYMENT PROFESSIONAL is the CRUISEHOST solution for integrating supported payment providers and payment processes into customer booking journeys.

Depending on the market and project, supported providers may include:

• Stripe
• PayPal
• WSPay
• SIPay
• Other providers subject to technical evaluation

Yes, where a supported payment provider and merchant account have been configured.

Yes, if PayPal is available in the relevant market and has been configured for the responsible merchant.

The contracting merchant normally requires its own account with the payment provider. CRUISEHOST provides the technical integration but does not automatically become the merchant.

Not necessarily. The payment flow depends on the merchant setup. Funds may be paid directly to the cruise line, travel agency, tour operator, host agency or another authorised merchant.

Payment details should be processed through the authorised payment provider and in accordance with applicable payment-security requirements. The exact technical flow depends on the integration.

Yes. Payment methods can vary according to market, currency, merchant and provider availability.

Yes. Depending on the business model, a booking can be completed with payment handled separately by the cruise line, agency or another responsible party.

BACKOFFICE refers to interfaces and processes that transfer booking, customer, payment or sales information from CRUISEHOST systems to external administration, accounting or mid-office systems.

Depending on the integration, data can be provided in formats such as:

• JSON
• XML
• CSV

Potentially, yes. The external system, available interface, required data and workflow must first be reviewed.

Yes. Automated booking-data transfers may be configured through an agreed interface.

Yes, where required, legally permitted and supported by the interface.

Payment and accounting-related data may be included depending on the booking model and external system requirements.

No. Some systems may already be supported, while others require an individual analysis or development project.

Yes. CRUISEHOST provides machine-assisted translation functions for supported website and catalogue content, including content translated from English into the configured target languages.

The available languages and translated content types depend on the customer's licence and market configuration.

CRUISEHOST uses DeepL for supported automated translations and provides DeepL Glossaries to improve the consistency of customer-specific terminology.

Earlier translation workflows also used a CRUISEHOST REPLACE function for fixed German-to-English terminology. The glossary functionality extends this quality-control principle to translations from English into other supported languages.

No. Machine-translation services can occasionally translate the same source word or phrase differently in another context. This is particularly noticeable in repeated cabin descriptions, cabin-category descriptions and cruise-specific terminology.

A term may be translated consistently many times and then receive a different translation in a later text. DeepL Glossaries reduce this risk by defining the required translation for selected words and phrases.

Yes. Translated content can be reviewed and adjusted where the respective content function allows editing. In addition, authorised users can define a required target-language translation in the DeepL Glossaries table.

Once a glossary entry has been updated and sent to DeepL, the defined wording is used during future translation sessions for that language pair.

Yes. Each market can have its own language, pages, promotions, cruise-line portfolio, pricing and commercial configuration. Glossary entries are maintained for the relevant translation agency and target language.

A DeepL Glossary is a quality-assurance list that defines how specific English words or phrases must be translated into a target language.

For every glossary entry, the customer can specify the approved translation. This helps ensure that future automated translations use the same terminology consistently.

The supplied documentation describes the glossary function for supported languages translated from English. An English source term is assigned an approved translation in the customer's target language.

Open the administration area of the relevant translation agency. Under the menu item Translation, select DEEPL GLOSSARIES.

The table contains English terms that CRUISEHOST has already standardised for the English translation from German. These terms provide a useful starting point for checking whether the translation into your own language matches your preferred terminology.

If you agree with the automatically proposed translation, no further action is required for that term.

1. Open Translation → DEEPL GLOSSARIES.
2. Find the required English term.
3. Click the term to copy it into the editable target-language field.
4. Enter or correct the required translation.
5. Click Update.

After clicking Update, the table displays the date and time of the change. This provides a record of when a word or phrase was last fixed in the glossary.

Yes. The glossary table can be used to define an approved translation for any relevant word, term or phrase made available in the function. Future translation sessions can then use the same approved wording.

Yes. Use the filter function to search for specific words and phrases in the glossary table.

Yes. Saving individual entries with Update is not the final step. After completing the changes, you must use the button that sends the glossary list to DeepL.

Only after this transmission will the updated glossary be available for future translation sessions.

The administration shows the date and time of the most recent glossary transmission to DeepL. Use this status to confirm that the latest terminology changes have been synchronised.

Update saves the individual word or phrase in the CRUISEHOST glossary table.

Send to DeepL transmits the completed glossary list to the translation service so it can be used in future translation sessions.

The updated terms are available for future translation sessions after the glossary has been sent successfully to DeepL.

The documentation does not state that previously translated content is automatically retransmitted or rewritten. Existing translations may therefore require a new translation process or manual review.

Start with terminology that occurs frequently or has a specific commercial meaning, for example:

• Cabin types and cabin-category names
• Board and beverage-package terms
• Fare and rate names
• Booking and option terminology
• Package and Travel Component names
• Product names that should not be translated
• Brand-specific wording
• Terms that have previously been translated inconsistently

No. A glossary improves terminology consistency, but it does not guarantee that every complete sentence is correct in its context.

Important marketing statements, legal information, booking conditions and customer-facing instructions should still be reviewed by a qualified speaker of the target language.

1. Review translated cabin, fare, package and website content.
2. Record words or phrases that are inconsistent or unsuitable.
3. Open Translation → DEEPL GLOSSARIES.
4. Search for each affected source term.
5. Enter the approved target-language translation.
6. Click Update for each changed entry.
7. Review the complete list.
8. Send the glossary to DeepL.
9. Confirm the last transmission date.
10. Check the terminology again during the next translation session.

Yes. CRUISEA offers can be transferred to a connected application using an agreed integration method and data format.

A browser-based integration can transfer structured offer data to the parent application through a secure messaging workflow agreed for the project.

A local application can use an agreed protocol handler or another supported transfer method to receive the encoded offer data.

It can include cruise line, ship, itinerary, dates, cabin category, passenger count, selling price, currency, booking channel, images, descriptions and links, depending on the interface version.

A short record is a compact booking-data export intended to provide the essential fields required by a connected back-office system.

A long record is a more extensive structured export that can include detailed booking, passenger, itinerary, pricing and service information.

Yes. XML interfaces are available for defined legacy and back-office integration scenarios.

Yes. Modern integrations can use JSON where this is supported by the selected interface or API.

CSV exports can be provided for defined reporting or back-office requirements, subject to the selected interface and project scope.

The trigger depends on the workflow and can be linked to an option, confirmed booking, status change or scheduled export.

Yes, when resending or status updates are supported. The receiving system should use stable booking identifiers to avoid duplicate records.

CRUISEHOST and the receiving system provider agree the required fields, formats, identifiers and transfer rules during the implementation project.

Documents can be linked or made available separately where supported. The exact method depends on the cruise line, document source and back-office interface.

Errors should be logged with a transaction or booking reference. The sending and receiving teams then determine whether the record should be corrected, retried or resent.

No. Historical documentation explains established concepts, but the current project documentation and agreed interface specification are authoritative for new implementations.

Yes. The available portfolio can combine different cruise segments according to the customer market and connected suppliers.

Yes. Portfolio visibility can be adjusted when a cruise line should be removed from search or booking for commercial or operational reasons.

Yes. Portfolios can be controlled by agency, group, host relationship, market or other agreed configuration.

Yes. The catalogue can present cruise-only content and customer-created packaged products where the selected solution supports both.

Yes. Customer-created packages can include dedicated titles, descriptions, images, included services and marketing text.

The available price presentation depends on the supplier data, market rules and customer configuration.

Yes. Passenger ages and supplier rules can affect availability and pricing, so the live request must use the correct passenger data.

Sorting and ranking options can be configured or developed according to the selected product and project scope.

Catalogue updates and live validation help reduce outdated results, but availability can still change between search and selection.

Yes. Content can be supplied, maintained or translated in multiple languages according to the selected language services and catalogue.

Image Wizzzard is the CRUISEHOST image database and image-management solution. It allows customers to upload, organise, search and reuse their own image material throughout supported CRUISEHOST products and website functions.

You can open the image database at:

https://cpm.cruisehost.net/image/image_database

Access must be enabled for your CRUISEHOST account.

Images stored in Image Wizzzard can be used in many CRUISEHOST areas, including:

• Website sliders
• Promotional panels
• Newsletters
• Headers and footers
• PAGEMAKER content pages
• Customer-created packages
• Other functions that require an image URL

Many CRUISEHOST functions load images through a web address rather than through a local computer file. Image Wizzzard gives each uploaded image a reusable URL that can be entered wherever an image address is required.

Yes. Images used on a secure website should be accessible through an https:// URL. This prevents mixed-content warnings and browser errors for customers visiting the website.

Images are organised with hashtags rather than a traditional folder structure. When uploading an image, you assign suitable hashtags that describe its content, destination, cruise line, campaign or intended use.

This makes it possible to find the same image through several relevant search terms without storing duplicate copies in different folders.

Use the assigned hashtags and search terms to locate suitable images. Good tagging is important because it allows images to be found by subject, cruise line, ship, destination, campaign or content type.

Yes. During upload, the image is optimised and compressed to approximately 10% of its original file size without a noticeable loss of visual quality under normal website use.

The optimisation process uses a Google image-compression service. Smaller image files improve page-loading performance and reduce unnecessary data transfer.

Large image files can slow down a website, especially on mobile connections. Optimised images improve loading speed, reduce bandwidth and support a better customer experience. Faster pages can also contribute positively to technical SEO.

Open Image Wizzzard, select the upload function, choose the image from your computer and add meaningful hashtags. The system then uploads, optimises and stores the image and makes its URL available for use.

Yes. Image Wizzzard includes a replace function for updating existing image material. This is useful when an image is already used in several places and should be exchanged without rebuilding all related content.

Yes. Customers using CRUISECUSTOMIZER can use their own image material for customer-created packages and replace standard images where the package configuration supports this.

This helps present more individual content and gives packaged products a distinctive visual identity.

By using your own licensed image material, you can create pages, panels, newsletters and packages that look different from standard supplier content. Unique visual presentation strengthens the brand and helps distinguish your website and offers from competing travel sellers.

Image Wizzzard supports SEO indirectly by enabling original visual content and optimised image files. Unique images can make landing pages and packages more distinctive, while smaller files improve page performance.

For the best result, the surrounding PAGEMAKER content should also use descriptive text, meaningful page headings and suitable image alternative text.

No. Image Wizzzard is an optional addition to the CRUISEHOST licence and must be activated for the customer account.

Yes. CRUISEHOST can grant six months of free trial access. Contact CRUISEHOST to request activation for your account.

Image Wizzzard is particularly useful for website editors, marketing teams, newsletter creators and package managers who regularly use their own image material in CRUISEHOST.

Use several clear and consistent hashtags for each image. Useful tags may describe:

• The cruise line or ship
• The destination or port
• The content type, such as slider, panel or newsletter
• The season or campaign
• The package or product theme
• The visual subject, such as beach, hotel, flight or family

A consistent tagging convention makes the image database much easier to maintain as it grows.

Yes. Once an image has been uploaded, its URL can be reused in multiple supported areas such as a slider, panel, newsletter, page or package.

You should upload only images that your company is legally permitted to store, edit and publish. The customer remains responsible for image licences, copyright, model releases and any usage restrictions attached to the image material.

These settings determine which company is shown as the legal tour operator for a cruise or package and which legal information is provided to the customer.

The configured information can be used in precontractual information, website displays, customer emails and PDFs.

The customer must be informed which company is legally responsible for the travel product. Depending on the product, this may be the cruise line, the agency acting as tour operator, or another registered tour operator.

If you sell cruises or packages as the legal tour operator, enter the following information under General:

• Your company and address details
• Details of your customer deposit insurance or insolvency protection
• Your own terms and conditions

Depending on the process and configuration, the responsible tour operator's information and terms can be shown on the website before the request or booking and provided afterward as part of the customer documentation or PDF.

CRUISEA users can also receive access to the relevant information before completing an option or booking.

The Cruise Line Name table lists the cruise lines available in the agency's cruise-line acceptance configuration.

By default, the cruise line is selected as the legal tour operator. This can be changed where the agency or another company is legally responsible.

For the relevant cruise line, select the radio button in the column I am Tour Operator for and save the setting.

The system then uses the agency information entered under General for that product.

Yes. Select the Custom Tour Operator option for the relevant cruise line or package and maintain the appropriate organiser information.

The Matchcode Name table manages tour-operator responsibility for authorised cruise-line packages in the agency catalogue.

The cruise line is selected by default, but the agency or a custom tour operator can be assigned instead.

After changing the radio-button selections, save all changes with the Edit button at the bottom of the page.

Yes. When creating a package, select the appropriate organiser in the Tour Operator field.

Packages that already exist can be managed through the Matchcode Name table.

The Cruise Lines menu contains cruise-line-specific legal and contact information that can be supplied to customers for requests, options and bookings.

For every cruise line you intend to sell, maintain the cruise line's contact details and the relevant customer-deposit or insolvency-protection information.

Yes. Upload the current terms and conditions for the cruise line and save the changes. The uploaded document may be forwarded or made available to the customer as part of the booking process.

• Confirm who is the legal tour operator for each cruise line and package.
• Maintain the agency's full legal details when acting as organiser.
• Maintain insolvency-protection or customer-deposit information.
• Upload current terms and conditions.
• Check the Cruise Line Name assignments.
• Check the Matchcode Name assignments.
• Save changes with the Edit button.
• Test the precontractual information and customer documents.
• Repeat the review whenever products or legal documents change.

CRUISEHOST is a technology provider specialising in cruise sales and cruise booking solutions. We provide travel agencies, cruise specialists, tour operators, host agencies, travel agency chains and online travel companies with the technology they need to search, present, sell and manage cruises.

It means that CRUISEHOST provides the technical infrastructure required to turn cruise content into searchable, comparable and bookable products. Our solutions connect cruise lines, travel sellers and customers through professional booking engines, websites, APIs, customer offers and booking-management tools.

No. CRUISEHOST is primarily a technology provider. We supply the software and infrastructure used by travel agencies, tour operators, cruise specialists, host agencies and online travel companies.

CRUISEHOST solutions are suitable for:

• Independent travel agencies
• Cruise specialists
• Home-based travel agents
• Host agencies
• Travel agency chains
• Tour operators
• Online travel agencies
• Affiliates
• Destination and tourism companies
• Technology companies requiring cruise content through an API
• Companies building their own cruise booking platforms

CRUISEHOST supports customers and cruise sales operations in numerous international markets. The available cruise lines, currencies, languages, prices and booking functions may vary according to the customer, market and licence configuration.

Yes. CRUISEHOST supports multilingual cruise sales environments. The exact languages available depend on the selected product and configuration.

Yes. Depending on the connected cruise line, market and customer configuration, cruise prices can be displayed and processed in different currencies.

No. Each customer can have an individual catalogue configuration. This may include different cruise lines, markets, languages, prices, mark-ups, packages, commissions, currencies and sales rules.

Yes. CRUISEHOST is designed to support different cruise distribution models. The available configuration depends on the selected products, connected cruise lines and commercial agreement.

CRUISEHOST technology is used by thousands of travel agencies and on a large number of cruise websites in international markets.

The CRUISEHOST product portfolio includes:

• CRUISEA for professional cruise search, sales and booking
• CRUISEAfree as a free entry-level solution
• CRUISEAlight as an extended entry-level solution
• CRUISEC for customer-facing cruise websites and booking engines
• PAGEMAKER as our content management system
• CSS CUSTOMIZER for advanced website styling and CRUISECUSTOMIZER for modular cruise packaging
• CRUISE-API for integration into third-party systems
• SmartOffer 360 for interactive customer offers
• SmartOption for creating cruise options with limited passenger information
• CRUISE-HUB for host-agency and subagency management
• PAYMENT PROFESSIONAL for payment integrations
• BACKOFFICE interfaces for the transfer of booking and customer data

No. The required products depend on your business model. A travel agent may only require CRUISEA, while an online travel agency may combine CRUISEA, CRUISEC, PAGEMAKER, PAYMENT PROFESSIONAL and BACKOFFICE. A technology company may primarily require the CRUISE-API.

Yes. Our products are designed to work together. For example, offers created in CRUISEA can be sent to customers through SmartOffer 360, while bookings generated through CRUISEC can appear in the CRUISEA booking management area.

A typical process includes:

• Searching for a suitable cruise
• Selecting the sailing and cabin category
• Requesting current prices and availability
• Entering customer and passenger information
• Reviewing the booking details
• Creating an option or confirmed booking
• Receiving a booking confirmation
• Managing the booking through CRUISEA or a connected system

The required information is defined by the cruise line and may include:

• Full legal name
• Date of birth
• Gender where legally or operationally required
• Nationality
• Address
• Email address
• Telephone number
• Passport or identity-document information
• Emergency contact details
• Loyalty programme number

Yes. Passenger names should be entered exactly as shown in the passport or identity document that will be used for travel.

Changes may be possible, but they are subject to the cruise line’s rules, availability, deadlines and fees.

Name changes depend on the cruise line and fare conditions. Fees or cancellation and rebooking may be required.

Yes, subject to the cruise line’s cancellation conditions. Cancellation fees may apply.

No. Cancellation fees and conditions are determined by the cruise line, tour operator or contracting travel provider.

The contractual relationship depends on the booking model. The contract may be between the customer and the cruise line, tour operator, travel agency, host agency or another authorised contracting party.

Travel documents are generally issued by the cruise line, tour operator or responsible travel provider. CRUISEHOST may make documents available through the connected system.

Depending on the cruise line and integration, travel documents may be available in CRUISEA, the booking-management area, the cruise-line system or through the responsible travel provider.

Yes. Automated confirmation emails and documents can be configured depending on the booking process and customer setup.

Single Sign-On (SSO) allows a user to enter an authorised CRUISEHOST application from a connected partner system without completing a separate manual login.

Yes. A single sign-on integration can be developed if the external platform and authentication process meet the technical requirements.

Automated provisioning may be possible as part of a single sign-on or user-management integration.

Yes. Permissions can be assigned according to user role, organisation, agency or system configuration.

Yes. Authorised administrators can request or perform deactivation according to the available administration functions.

After the commercial agreement has been completed, the project is transferred to the CRUISEHOST implementation team. A project manager coordinates the setup, required information, configuration, testing and launch.

For implementation projects, CRUISEHOST normally assigns a project manager who serves as the primary contact during the project.

Depending on the project, CRUISEHOST may require:

• Company details
• Agency details
• Market and country information
• Logo and brand guidelines
• Domain information
• Languages
• Currencies
• Required cruise lines
• Cruise-line agency numbers or credentials
• Payment-provider information
• Booking and customer communication requirements
• Legal texts
• Privacy information
• Terms and conditions
• User lists
• Back-office requirements
• Design material

In many cases, yes. The customer may require its own commercial agreement, agency registration or booking credentials with the relevant cruise line. The exact requirements vary by cruise line and business model.

CRUISEHOST can assist with information and coordination, but approval and commercial access are determined by the cruise line.

Credentials are configured securely for the authorised customer environment and should only be used for the agreed purpose.

Yes. The configured functions are tested before launch. Customers are also expected to review and approve their website, content, prices, legal information and booking processes.

Customer acceptance testing is the phase in which the customer reviews the configured solution and confirms that it meets the agreed requirements before launch.

CRUISEHOST tests the technical implementation, while the customer is responsible for reviewing and approving its branding, content, legal texts, commercial rules, payment details and business-specific configuration.

Changes may be possible. Additional requirements can affect the project plan, workload and cost and may require a separate quotation.

Content and data migration may be possible, depending on the existing system, available data formats and agreed project scope.

Yes. Existing domains can normally be connected to the new solution, provided that the required DNS and technical access are available.

Yes. A phased launch is possible, with additional cruise lines, markets or functions added later.

Yes. Multi-market implementations are possible, but each market may require separate catalogue, language, currency, legal, payment and cruise-line configurations.

CRUISEHOST uses dedicated communication channels for support, project and sales enquiries.

• Technical and operational support requests should be sent to the designated support address.
• Implementation and project questions should be sent to the designated project address.
• Commercial and licence enquiries should be sent to the designated sales address.

Please include:

• Your company or agency name
• Your AgencyID or customer number
• The affected product
• A clear description of the issue
• The date and time of the issue
• The affected booking or cruise where applicable
• Screenshots
• The browser and device used
• The steps required to reproduce the issue
• The exact error message

The AgencyID helps CRUISEHOST identify the correct customer configuration, market, catalogue and technical environment more quickly.

No. Please send the request to the most appropriate address. Sending the same request to several addresses can create duplicate tickets and delay processing.

Yes, but please add an explanation of the problem, the relevant AgencyID and the action you require. A forwarded email without context may not contain enough information for investigation.

A technical problem may include:

• The system cannot be opened
• A search does not load
• An availability request fails
• A booking cannot be completed
• A document cannot be generated
• A user cannot log in
• An interface returns an error
• A website component is not displayed correctly

Questions about cruise-line prices, cancellation rules, option periods, commission, contracts or booking conditions may need to be answered by the cruise line, tour operator or responsible commercial partner.

CRUISEHOST can investigate technical issues, but booking changes, cancellations and exceptions are generally controlled by the cruise line or responsible travel provider.

Yes. Training, onboarding material, documentation and product demonstrations may be provided depending on the product and agreement.

Additional training can be arranged. Customers should also maintain internal processes for introducing new team members to their configured CRUISEHOST environment.

CRUISEHOST uses technical and organisational measures designed to protect personal, commercial and booking data against unauthorised access, loss or misuse.

CRUISEHOST processes data according to the applicable contractual and legal requirements. Customers are also responsible for ensuring that their own use of the platform complies with the data-protection laws applicable to their business.

The company collecting and using the customer’s personal data is responsible for providing the required privacy information and obtaining any legally required consent.

Only where legally permitted and where the required consent or other legal basis exists.

Data may only be shared where this is necessary for the agreed service, legally permitted and contractually secured.

Only where explicitly permitted by the relevant agreement. Customer-specific cruise data, prices, credentials and booking access must not be disclosed or reused without authorisation.

No. User access should be assigned to authorised individuals or organisations according to the agreed licence. Login credentials must not be shared with unauthorised third parties.

The user account should be deactivated promptly and any shared credentials should be changed.

Yes, if authorised and if appropriate confidentiality, security and data-processing agreements are in place.

CRUISEHOST may use AI-supported functions for selected purposes such as translation, content processing, search assistance or future sales-support functions.

Only with explicit approval and an appropriate technical and contractual agreement. Cruise catalogue, pricing, availability and customer-specific data must not be transferred to an unauthorised AI system.

CRUISEHOST data can include licensed cruise-line content, live prices, customer-specific commercial information, credentials and personal data. Uncontrolled transmission to an AI service could create confidentiality, data-protection, intellectual-property and contractual risks.

No, unless this has been expressly reviewed and approved. Data used for an authorised AI application must remain restricted to the agreed purpose and environment.

AI-supported recommendation functions can be developed where data use, security, accuracy and customer-specific catalogue rules are properly controlled.

CRUISEA licence prices depend on the selected version, number of users, market and commercial agreement. Standard prices may start from approximately EUR 15 per month, but the current quotation is always authoritative.

CRUISEAfree is provided without a monthly software licence fee for the included standard scope.

CRUISEC pricing depends on the implementation model, website configuration, booking volume, turnover, additional products and services. A standard CRUISEC and CRUISEA combination may be offered from approximately EUR 120 per month, subject to the current commercial model.

Yes. An iframe version may be available with a separate monthly licence, depending on the required functions and current price list.

Depending on the product and agreement, booking fees, turnover-based fees or API transaction fees may apply.

API pricing depends on the API version, usage, booking volume, catalogue access and commercial agreement. Models may include a monthly minimum, a fee per booking or a capped monthly catalogue fee.

Minimum contract periods depend on the selected product and commercial agreement. Some API agreements may include a minimum term of twelve months.

Billing dates and payment terms are defined in the customer agreement. Monthly fees may be collected at the beginning of the billing period.

The payment may be retried according to the agreed billing process. Continued non-payment can result in suspension of the service.

Yes. Products, users, markets, languages, cruise lines and additional functions can be added according to availability and agreement.

Downgrades are subject to the contractual notice period, technical dependencies and minimum product requirements.

Yes. Additional users can be added according to the selected product and price model.

Standard product operation is covered by the licence. Individual design, data migration, custom development, special interfaces, additional training and project work may be charged separately.

The applicable quotation or invoice states whether VAT is included or added. Business prices are commonly quoted excluding VAT.

This depends on the customer’s country, tax status and valid VAT identification information. The applicable tax treatment is determined according to legal requirements.

Prices may be adjusted in accordance with the customer agreement and applicable notice periods.

Yes. Deep links, landing pages, cruise selections, promotional content and customer offers can be used to support email marketing campaigns.

Yes. Deep links can direct the recipient to a specific cruise, ship, cruise line, destination or predefined search result.

Yes. PAGEMAKER can be used to create dedicated pages for individual cruise lines and their offers.

Yes. Pages can be created for destinations such as the Mediterranean, Northern Europe, the Caribbean, Alaska, Asia or other cruise regions.

Yes. Ship pages can include descriptions, facts, images, facilities, deck plans and matching cruises.

Yes. Search results, widgets, manual selections and deep links can be used to promote selected cruises or campaigns.

Yes. SmartOffer 360 is specifically designed to help travel agents follow up with customers using personalised cruise selections.

Yes. Links and documents can be shared through WhatsApp, provided that the agency complies with applicable data-protection, communication and consent requirements.

A current version of a modern browser such as Google Chrome, Microsoft Edge, Mozilla Firefox or Safari is recommended.

CRUISEA, CRUISEC and PAGEMAKER are browser-based solutions. Normally, no local software installation is required.

Many functions can be accessed on tablets, although a desktop or notebook computer may provide the best experience for complex searches, offers and booking administration.

Some functions may be accessible on a smartphone, but the professional workflow is generally optimised for larger screens.

No customer-operated server is normally required for the standard hosted solution. Individual API or integration projects may have additional technical requirements.

Yes. CRUISEHOST continuously develops and maintains its products. Updates may include technical improvements, cruise-line changes, security updates and new functions.

Standard updates are designed to maintain compatibility, but major product developments or cruise-line changes can occasionally require adjustments.

CRUISEHOST reviews and adapts the relevant connection. Temporary restrictions may occur while a changed cruise-line interface is analysed, developed and tested.

No. CRUISEHOST depends on external cruise-line systems, networks and service providers. Temporary interruptions outside CRUISEHOST’s control can occur.

Retry the request after a short period and report persistent errors to CRUISEHOST support with the AgencyID, cruise, date, time and error message.

Yes. Customer-specific packages, calculations and additional services can be supported where the required data and booking processes are available.

A technical setup may focus primarily on CRUISEC or the CRUISE-API, but CRUISEA is often used for booking administration, customer service and manual sales support.

Yes. Customers can search and book through CRUISEC while call-centre or agency employees use CRUISEA to assist customers and manage bookings.

Yes. Bookings from CRUISEC, CRUISEA and supported API channels can be brought together in the relevant CRUISEHOST booking environment.

Different catalogues, calculations or commercial rules may be configured, subject to cruise-line and contractual restrictions.

Booking and reporting data can include channel, agency, user or source information depending on the implementation.

The search result may contain a previously received or catalogue price. The booking process requests the latest price from the cruise line, which may have changed.

The cabin may have been booked by another customer, removed by the cruise line or become unavailable for the selected passenger combination.

The option may have expired, the cruise line may have changed the booking, required passenger details may be missing or confirmation may no longer be permitted.

The response time depends on the external cruise-line system and network. Temporary delays can occur during periods of high demand or system maintenance.

The booking was recorded in CRUISEHOST but was not transmitted as a confirmed booking to the cruise-line reservation system. This may be intentional in a test environment or for a non-live booking workflow.

The cruise line may not be included in your catalogue, may not be available in your market or may require additional credentials or a commercial agreement.

The promotion may be restricted by market, agency, loyalty status, passenger type, booking date, sailing date or cruise-line credentials.

The cause may be cached browser content, custom HTML, an image size, an external script or a responsive-layout issue. Please test the page in a current browser and send support the affected URL and screenshots.

Check the username, password, account status and login address. If the problem continues, request a password reset or contact support with your AgencyID.

Check the email address, spam folder, mail-server filters and sending status. If necessary, resend the document and contact support with the booking or offer reference.

Contact the CRUISEHOST sales team or register for an available entry-level product such as CRUISEAfree. We will review your business model, market, required cruise lines and technical requirements.

Yes. CRUISEHOST can provide a product demonstration tailored to your business model and required products.

Yes. CRUISEAfree or another agreed test environment can be used to become familiar with the platform.

A demonstration or project-specific test environment may be provided as part of the sales and implementation process.

It is helpful to provide:

• Your company name
• Your country and target markets
• Your business type
• The number of users or agencies
• Your current website
• The cruise lines you want to sell
• Your expected booking volume
• Your required languages and currencies
• Your preferred payment flow
• Your existing back-office or CRM systems
• Your desired launch date

Yes. Based on your business model and objectives, CRUISEHOST can recommend a suitable combination of CRUISEA, CRUISEC, PAGEMAKER, CRUISE-API, CRUISE-HUB and other services.

Yes. Many customers begin with a smaller licence or limited cruise-line portfolio and expand to additional users, websites, markets, products or API connections later.

Please contact the CRUISEHOST sales team. Only an individual written quotation or signed agreement provides binding prices, functions and contractual terms.

No. The available functions depend on the selected product, licence, market, cruise lines, integrations and commercial agreement.

No. Any price examples are for general orientation only. The current CRUISEHOST quotation and customer agreement are authoritative.

Yes. Cruise lines can change their interfaces, prices, booking rules, option periods, content and technical availability at any time.

No. CRUISEHOST operates the CRUISEHOST platform but cannot guarantee the uninterrupted availability of systems operated by cruise lines, payment providers, hosting companies or other third parties.

The exact products, users, markets, functions, services and prices included in your licence are stated in your quotation, order confirmation and customer agreement.

Single Sign-On allows an authorised user to enter CRUISEA or CRUISEHOST from a connected partner system without a separate manual login. Depending on the agreed implementation, agency and user records can be created or updated automatically.

The connected system can provide user information, agency information, market settings, catalogue inheritance settings and cruise-line agency identifiers in the agreed data structure.

The partner creates a token and sends it to the agreed CRUISEHOST SSO endpoint. CRUISEHOST can return the token to a validation endpoint operated by the partner and receives the authorised agency and user data after successful validation.

Yes. Where this is part of the agreed integration, an agency record can be created automatically from the validated agency data.

Yes. User records can be created or updated from the data returned by the partner system, subject to the configured rules and required fields.

Integration data should be transmitted in UTF-8 so that names, addresses and international characters are handled correctly.

CRUISEC SSO allows a customer or member to authenticate through an external login system and then enter a restricted CRUISEC environment using a generated token.

Yes. CRUISEC can be configured so that unauthenticated visitors are redirected to the customer’s own login page.

Depending on the implementation, the request can contain customer details such as name, address, contact information, date of birth and nationality, together with the agency identifier and security credentials.

After a successful authentication request, the returned token is added to the CRUISEC URL so the authenticated user can continue in the restricted booking environment.

Yes. Session and inactivity rules can be configured as part of the implementation. The exact current timeout should be confirmed for the customer project.

A direct-login URL may exist for defined internal or legacy use cases, but token-based SSO is normally preferable because credentials should not be exposed in browser URLs.

Automatic agency provisioning creates an agency record during the first successful SSO process instead of requiring the agency to be entered manually in advance.

Automatic user provisioning creates or updates a user from the identity data supplied by an authorised partner system.

Catalogue and configuration inheritance can be assigned through agreed agency settings so that an agency receives the correct cruise lines, calculations, payment settings and layout configuration.

A Knowledge Base ID is a stable reference assigned to each article, such as KB-API-015. It helps support teams, customers, release notes and AI assistants refer to the same article consistently.

It should normally remain unchanged so existing links and support references continue to work.

Relevant articles appear in a See also area at the end of an answer and link directly to the corresponding Knowledge Base article.

Yes. Each rendered article receives a permanent page anchor, allowing a direct link to open that topic.

Yes. The search indexes the article title, answer, category, Knowledge Base ID and additional search terms.

Yes. Each editable article can contain keywords and synonyms that are used by the search without being displayed in the answer.

Copy one complete editable article block, assign a unique data-id and Knowledge Base ID, enter the question and answer, and optionally add keywords and related article IDs.

Copy one complete category block, change its heading and category code, and place the new article blocks inside it.

Yes. The structured questions, answers, IDs, categories and cross-references make the content suitable as a controlled source for an authorised CRUISEHOST AI assistant.

No. Each article must be read together with the customer’s licence, market, cruise-line access and project agreement.

A typical project involves the customer project owner, CRUISEHOST project management, technical contacts, design or content contacts and, where applicable, external system providers.

A project owner coordinates decisions, collects customer data, confirms priorities and helps prevent delays caused by unclear responsibilities.

Yes. A project can launch core functions first and add additional websites, markets, cruise lines, APIs or packaging functions in later phases.

Common causes include missing credentials, incomplete agency data, undecided designs, unavailable third-party interfaces, delayed content and untested payment or back-office processes.

Testing should begin as soon as the agreed test environment and the relevant end-to-end workflows are available.

Test search, live availability, passenger combinations, options, bookings, payments, emails, documents, mobile layouts and connected-system transfers.

No. A reliable launch plan depends on timely access to all required customer, cruise-line and third-party information.

Yes. Test bookings should use the agreed test process and references so they are not mistaken for genuine customer transactions.

The customer and CRUISEHOST confirm readiness based on the agreed scope, completed testing and any remaining accepted limitations.

Yes. Product and workflow training can be included or arranged according to the implementation scope.