Table of Contents

Basic Seaware Concepts

Sessions and Temporary Storage

Notion of session in Seaware is similar to what you can see in many other applications. This is user session that can be considered as user specific context to store temporary objects, apply security restrictions, etc. It is created when user logs in and destroyed when user logs out (or by timeout). In a sense this is a kind of state that is associated with the user in Seaware.

User Types

When integrating with the API, you can authenticate as different user types:

  • Travel Agents: Individual agents working on behalf of a travel agency
  • Travel Agency: Agency-level access for booking on behalf of your organization
  • Consumers: Direct customer bookings (B2C integrations)

API Usage Modes

The API supports flexible integration patterns. Versonix OTA API calls can be used in:

  • Session context: Login request provide sessionGUID, then subsequent requests use the session GUID, finally logout request destroys all temporary session objects
  • Stateful context: Booking management using temporary storage, ability to lock (create), edit, then store or unlock a booking
  • Stateless manner: Each request has it's own session/state context, no access to temporary storage (except special case of CabinHold) and user session, everything in a single call. Largely uses by GDS systems.

Common Objects

Booking Source

A booking source identifier must be provided in every request inside the POS element using the CompanyName field. This identifies your integration channel.

Your booking source will be provided during onboarding and determines which inventory, rates, and features are available to your integration.

Agency and Agent

Agency represents a Travel Agency in the system. All reservations must be made on behalf of an agency. This could be your travel agency, or a virtual agency for direct customer bookings.

Agent is an individual staff member associated with an agency. Agents can make bookings on behalf of their agency.

The API supports authentication at either the agency level or individual agent level, depending on your integration needs.

Client, Household and Reservation Guest

Client is the end customer who will be traveling on the cruise. Client records store customer information, preferences, loyalty program details, and booking history.

Household is a concept to define family in Seaware. Each client must belong to some household object (even if it is the only member of that household). This concept is used to:

  • Decrease number of data stored in the database – some information common for all the family members (like addresses, phones, etc.) is stored just once for all the family members.
  • Record activities at family level. It is useful to produce some family specific marketing materials, promotions, etc.

Guest is a reservation guest. This concept very differs from Client. Client is a real person, unique within the whole system. Guest is not a person (Guest ID is not equal to Client ID)! It is a kind of placeholder for a client in a reservation. This is an abstract reservation component and should be unique within a reservation only. In the end of booking process each guest must be associated with the client (it's obvious – real person is supposed to travel) but at some moment in the booking process reservation can have unnamed guests, not associated with any real persons.

The API handles household relationships automatically. When you create client records, the system manages household associations based on your account configuration.

Sail Activity and Sail

Seaware has two concepts to define ship sails: Sail Activity and Sail.

Sail Activity object is related to Sail Calendar and can be considered as an event that happens with some ship at some specific time in some specific port. For example, Sail Activity could look like: "Ship A has departure at 01.01.2011 12:00 in port B pier C". Other types of sail activity events could be: arrival, repair, etc. (all activities are customizable). Set of sail activities define sail calendar for some ship. Many objects in Seaware reference to sail activities, mostly to departure and arrival events.

Sail is a concept that is related to ship sailing activities that are available to sell. Sail is defined as a process (or time interval) between two sail activity events: departure and arrival. In other words sail is a moving of a ship between two ports.

Package

Package concept is related to products that can be sold in Seaware. There are two kinds of packages: primary package and dynamic package.

Primary Package defines the main product in Seaware – sail (voyage). Formally speaking this is a moving between two ports on some ship at specific date. Currently primary package can contain one sail only. Primary package is not mandatory for reservation but if reservation is made for some sail that sail must be included in form of primary package object.

Addon

Addon object represents a complimentary product or service that can be provided on board or on shore in addition to main package products. The most often used addons are: breakfast, dinner, insurance, etc. In additional to manually added addons it's possible to tell Seaware to add addons automatically because of some conditions (defined by business rules).

Allotment

Allotment feature in Seaware is intended to allow reserving some inventory (cabins or car deck space) for some customers. If customer has allotment this guarantees them availability of specific amount of cabins in specified cabin category or some space on card deck.

Allotment ID should be specified at reservation time in order to tell the system that you are going to reserve accommodations from allotment. If there are no space in allotment that accommodations will be taken from common inventory.

Accommodation Request and Inventory Allocation

Each reservation made in the system requires a part of general ship inventory in order to accommodate reservation's guests and cars. At reservation time this inventory is requested. These requests are made in form of general availability data without specifying allocation details. For example, reservation requests some amount of places or cabins of some specific category. If there are available cabins of requested category they are reserved for this reservation but real places or cabins are not allocated. If there are no available cabins of such category this request can be put in wait list.

Real inventory allocations are made when cabin assignment is done (usually some time before check-in or during check-in). During this process reservation accommodation requests get exact places in a ship – cabin numbers. If there are no more inventories for wait listed accommodations they are refused.

Reservation

Reservation object is the central object in the system. The core of Seaware is booking engine and the core functionality is booking management. Reservation object can contain many child objects.

Some of them can be specified in corresponding request message (when reservation is supposed to be created). These children represent reservation guests, accommodation requests, products to purchase (packages, addons), promotions to apply, etc.

Other children are output only – they show reservation specific information that is calculated by Seaware. These are mostly pricing and accounting specific objects.

Group

Group in Seaware is a kind of booking. Group has inventory request, for example, several cabins on a sail plus car deck, etc.

Inside the Group simple reservations are created which are Group Delegates. They use inventory from the Group request. These Delegates have the Group ID value on them unlike simple reservations which have this field empty.

So Group is a kind of shell above simple reservations. Group usually is created for a Travel Agency to occupy inventory. Later on Travel Agency makes Delegate bookings from this Group request.

The API supports creating bookings as part of existing groups (group delegate bookings), but does not support group creation or modification.

Travel-With Functionality

Seaware has an ability (exposed in Versonix OTA API as well) to define a kind of reservation affinity. Some reservations (effectively, their guests) can be marked as traveled together in order to get some preferences in the future (like cabins close to each other, seats on the same table in the restaurant, etc.).

Code Mappings

The API uses standardized OpenTravel Alliance (OTA) code lists for most values (ports, countries, document types, etc.). Some codes may have custom mappings specific to your integration - these will be documented in your integration guide or provided during onboarding.