Skip to main content

Frequently asked questions

Questions that come up repeatedly during onboarding. Both answers below came from the developer forum, which is being retired — they are folded in here so they survive.

Is there an endpoint that lists all bookings?​

No. GET /v2/bookings/details is the only read endpoint for bookings, and it needs a providerBookingId or a holiduBookingId you already hold. There is no collection endpoint, no date-range filter and no pagination over bookings — nothing of the shape GET /v2/bookings?from=…&to=…. There is also no backfill endpoint for historical bookings.

The real-time booking notification is how you learn about a booking: you receive it on your own endpoint when the booking is made, and you are expected to persist the identifiers from it. GET /v2/bookings/details is then a lookup for a booking you already know about, not a way to discover bookings.

Worth checking before you build

This API exists so a channel manager can push inventory to Holidu as a distribution channel. If you are building an invoicing or reporting tool that needs to read bookings in bulk, the Connectivity API is probably the wrong integration point — that data lives in the channel manager's own API. Raise it with your technical account manager before you start.

From the developer forum.

Can I send multiple extra costs with the same name?​

Yes. A single extra cost carries exactly one seasonApplicable range, so you cannot express several seasons inside one entry. You model season-dependent pricing by sending several entries that share a name, each with its own id and its own seasonApplicable range. The endpoint takes a list, and uniqueness is enforced on id only — never on name.

A tourist tax that changes partway through the season:

Two seasons, one name
[
  {
    "id": "TAX_2026_AUG_OCT",
    "name": "TOURIST_OR_CITY_TAX",
    "basisOfCalculation": "PER_PERSON_PER_NIGHT",
    "type": "MANDATORY",
    "paymentTime": "ONSITE",
    "price": { "type": "FIXED", "amount": 2.5, "currency": "EUR" },
    "condition": {
      "seasonApplicable": {
        "onlyApplicableFrom": "2026-08-01",
        "onlyApplicableUntil": "2026-10-09"
      }
    }
  },
  {
    "id": "TAX_2026_OCT_DEC",
    "name": "TOURIST_OR_CITY_TAX",
    "basisOfCalculation": "PER_PERSON_PER_NIGHT",
    "type": "MANDATORY",
    "paymentTime": "ONSITE",
    "price": { "type": "FIXED", "amount": 3.5, "currency": "EUR" },
    "condition": {
      "seasonApplicable": {
        "onlyApplicableFrom": "2026-10-10",
        "onlyApplicableUntil": "2026-12-10"
      }
    }
  }
]

Two things to get right:

  • Every entry needs a distinct id. Duplicate ids in one request are rejected with Extra costs for apartment contains duplicate ids.
  • Keep the ranges non-overlapping. Ending the first range on 2026-10-09 rather than 2026-10-10 avoids a day that matches both entries.

Note that name is an enum (ExtraCostName), not free text, so a tax maps to a value such as TOURIST_OR_CITY_TAX or ECO_TAX. Every season variant reuses that same enum value.

From the developer forum.