Access, Supplier and Context
On this page you will learn more about Core Entities used in HotelX. You can also refer to the overarching core concepts that apply to all TravelgateX APIs.
A party that supplies accommodation services through a Supplier API implementation. Each
Supplier has a
Supplier code. These are unique values and they are used consistently throughout all TravelgateX implementations. See our Supplier database, or ask us via our Jira Service desk for a list of
Since not all suppliers have their own API, in some cases they will use a third party platform to return availability and allow you to make reservations. This is generally transparent to you as a customer.
Accesses are displayed as numeric codes in Hotel-X and represent
Supplier configurations for a given credential. Those configurations include:
An access is used by just a client exclusively. The same supplier has different access depends on the number of clients connected to him, even if the configuration is almost the same.
A party that buys accommodation services through Hotel-X API implementation.
Client codes are consistent throughout all TravelgateX implementations. These codes are used to identify the business that is making the request and to confirm that the business has a configuration assigned to it.
Context is the way how a client/supplier define hotel, board and room codes among others. Each
Profile (either a
Supplier) can manage their own contexts or reuse existing ones. Different buyers or sellers can also manage the same codes context. For example, the
SupplierSmyRooms uses LOGI contexts for their implementations.
Context applies to:
With our built-in solution, you are able to choose the context that you wish to use when requesting a HotelX operation. For example, if you are a
Buyer, you can map your context against your Supplier contexts.
Should you be using the aggregator mode, we recommend that you use you own
Context- in doing so, all supplier mappings will be solved/unified.