Finding and Using Amenity Codes to Properly Configuration The Hub For Barefoot Customers
Background
Barefoot (BF) does not have a normalized view of amenities on their platform, meaning each client can have different amenity names, values, and types (checkbox, dropdown, textboxes, etc). Furthermore, BF sends the amenity codes in the API responses and these codes are the internally generated keys, typically beginning with the letter ‘a’ and will vary from client to client.
| Amenity Code | Amenity Name | Amenity Value | |
|---|---|---|---|
| Client A | a231 | BBQ | 0 |
| Client B | a475 | BBQ Grill | 1 |
*The initial HUB BF implementation had all of the amenity codes hardcoded to one client, therefore not permitting another client from using the Q4Launch VR Platform.
Implementation Details
To allow for new BF VR clients, the HUB BF implementation was refactored to use an amenity code mapping that is configured during the client onboarding process in the hub. In the HUB’s “Your Setting” configuration screen for the BF VR client, the screen shows additional settings to configure the amenity code mapping as shown below:
The above entities are the “core” entities on the VR platform and are used to drive other features on the platform. All clients should have amenities that represent each core amenity above. The “Excluded Amenity Codes” are those that should not flow through to the amenity section of the property detail page.
Once the above has been configured, the properties can now be synced via the VR Plugin. When the VR Plugin calls the HUB during the property sync, the HUB uses the codes provided in the mapping (example shown above) to process the core amenities.