Adding Contacts from a Hotspot

Table of contents¶

• Introduction
• Aspects to consider
• How does it work?
• Existing contact
• Example

Introduction¶

This article covers what to keep in mind when indicating the hotel where a guest performed a Wi-Fi login; to do so, HotelDataHub internally creates a movement in Fideltour.

Why create these movements?¶

The need to create these kinds of movements comes from how important the product or service consumed by each contact can be when segmenting them. The clearest example is this: if a contact has stayed at the hotel, they already meet the conditions to receive surveys or communications related to their stay. On the other hand, if the contact has only used a hotel service (pool, spa, restaurant, etc.), they aren't considered eligible for certain types of surveys or communications.

Aspects to consider¶

This HotelDataHub API v1 service is exclusively for external Wi-Fi captive portals, so it's essential to correctly indicate the contact's source (source=1); otherwise the movement isn't created. There's also another restriction to keep in mind: if the hotel isn't specified, or it isn't linked to the API user making the request, the movement isn't created either.

How does it work?¶

The provider must make a POST or PATCH request to contacts/, depending on whether it's a new or an existing contact, and the body of that request must include, at minimum, the "hotel" attribute, indicating the hotel's ID in Fideltour.

Optional movement attributes¶

⚠️ Important¶

• The attribute name is "hotel", NOT "hotel_id"
• booking_type must be 1 if the person using the Wi-Fi is staying at the hotel; otherwise use 2 (visitor)
• If entrance or departure is not in YYYY-MM-DD format or its year is before 1900 (e.g. 0226-10-07), a 400 is returned and neither the contact nor the movement is created

Existing contact¶

If the POST arrives with an email that is already registered, the source is Wi-Fi (source=1) or concierge (source=11) and the body includes a valid hotel, Hotel Data Hub looks up that contact, creates the movement and responds 200 with the existing contact's JSON. The contact's data is not modified; updating it requires a PATCH. If hotel is not sent, the original 400 error is returned, since there is no movement to create.

To avoid duplicate movements when the same guest logs in several times during their stay, if the contact already existed (both in this case and in a PATCH) the movement is not created when the contact already has one for the same hotel, the same channel (Wi-Fi or concierge), the same booking_type, and with entrance and departure differing by at most 1 day from the ones received.

Example¶

We want to register a contact who performed a Wi-Fi login at the hotel with id=1234. The following information was provided in the Wi-Fi form:

Request¶

POST https://app.hoteldatahub.io/api/v1/contacts/ HTTP/1.1
Content-Type: application/json

{
    "email": "juanserranolopez@gmail.com",
    "name": "Juan",
    "surname": "Serrano López",
    "birthday": "1990-11-21",
    "gender": 1,
    "hotel": 1234,
    "booking_type": 1,
    "entrance": "2024-03-05",
    "departure": "2024-03-10",
    "localizer": "ABC1234",
    "room_number": "300",
    "source": 1
}

Response¶

For a 200 or 201 response, you receive a JSON with all of the created contact's information.