DSA compliance

Learn how to utilise the trader information from the accommodations/details response to manage properties availability for EEA users, ensuring compliance with the Digital Services Act (DSA).

Introduction to DSA compliance

The Digital Services Act (DSA) and particularly, the Article 30 (Traceability of Traders) mandates online platforms to collect, verify, and display certain essential information about professional hosts (traders).

For platforms to remain compliant, they must display trader information for EEA travellers browsing or making bookings on their websites and apps. Failure to verify or collect the required trader data may result in restrictions on services for EEA users.

Key fields in DSA compliance

Demand API provides two key fields host_type and trader, which are included as "description" extras in the accommodations/details respose.

Example of request and response

Here's an example of the accommodations/details request including the "description" field as extras:

{
  "accommodations": [
    10507360
  ],
  "extras": [
    "description",
  ],
  "languages": [
    "en-gb"
  ]
}

Here's an example of the response including the host_type and trader fields:

{
  "description": {
    "host_type": "professional",
    "important_information": {
      "en-gb": "The credit card used to book a non-refundable rate will be charged on the day of booking and must be presented upon check-in..."
    },
    "license_numbers": [],
    "text": {
      "en-gb": "The Demand API sandbox Hotel Orion offers elegant accommodation alongside the famous Keizersgracht canal, near the Anne Frank House..."
    },
    "trader": {
      "address": {
        "address_line": "Keizersgracht 12345",
        "city": "Amsterdam",
        "country": "nl",
        "post_code": "1015CZ"
      },
      "email": "info@sandboxhotel.nl",
      "name": "Demand API sandbox Hotel Orion",
      "registration_number": "1234562",
      "telephone": "+31xxxxxxxxx",
      "trade_register": "Sandbox",
      "trader_verified": true
    }
  }
}

Interpreting host type and trader info

The following table explains how to interpret the host_type and trader fields and their significance for compliance:

Storing, and displaying trader information

As part of the DSA compliance process, it's important to handle trader information with care, especially since it contains Personally Identifiable Information (PII).

It is important to display and store trader information based on the host type classification, ensuring that the correct information is shown to EEA travellers.

Here are some suggestions for storing and displaying trader details:

Trader verification

To comply with DSA, Demand API provides a mechanism to expose current status in verification process by means of the trader_verified field included in the accommodations/details response.

This field indicates whether a trader has met the verification requirements, ensuring that only verified properties are displayed to EEA travellers.

Interpreting the true/false value

The trader_verified field can have one of two values: true or false.

The following table explains how to handle each value:

Caching strategy

The following table outlines the actions needed according to the caching strategy you are implementing for availability data:

Guidelines - Excluding properties for EEA travellers

If your system caches accommodation availability, you must take extra care to filter non-verified properties for EEA users.

Follow these guidelines to manually exclude them from results:

1. Filter by "host_type"

• Check the value of host_type
• Filter by "Professional" hosts.

Example:

{
  "description": {
    "host_type": "professional",
    ...},

2. Filter by "trader_verified: false"

• Check the value of trader_verified
• If the value is false , you should exclude the accommodation from your search and availability results to EEA travellers.

Example:

"trader": {
  "trader_verified": false
}

3. Filter by EEA country

Check the booker.country field included in the accommodations/search and availability requests to identify EEA travellers.

Example:

{
  "booker": {
    "country": "nl",
    "platform": "desktop"
  },

Apply restrictions to all EEA booker countries requests.

Handling private hosts

If the trader object has all the fields as null, this indicates the accommodation is listed by a private, non-professional host.

• The host_type field will also indicate this sort of host.

Example:

{
  "description": {
    "host_type": "private",
    "important_information": {
      "en-gb": "Guests are required to show a photo identification and credit card upon check-in..."
    },
    "license_numbers": [],
    "text": {
      "en-gb": "This property offers access to a terrace, free private parking and free WiFi..."
    },
    "trader": {
      "address": null,
      "email": null,
      "name": null,
      "registration_number": null,
      "telephone": null,
      "trade_register": null,
      "trader_verified": true
    }
  }
}

Benefits of this approach

By filtering accommodations based on the trader_verified and host_type fields, you ensure that only verified professional properties are shown to EEA travellers.

This approach:

• Helps you avoid displaying properties that may violate the DSA requirements, reducing the risk of non-compliance and ensuring a smooth user experience.

• Allows you to confidently display verified properties and exclude non-compliant listings, ensuring both legal compliance and the best experience for your users.