Register the four entity types on your account

By the end you will have one of each of the four entity types on your account — an accommodation, a location, a location search and a flight — which is what every Feed and Real Time endpoint asks you to point at.

What you need: an account with the Account API active. Nothing else.

What it costs: nothing. Creating entities is free. Resolving them against Booking is free too — you only pay when you ask for data about them.

What an entity is, and why there are four

An entity is a thing you have told Veetal to watch. The endpoints don't take free text: they take your identifiers. Which type you need depends on the question:

All four live under My organization, each on its own tab, and all four can also be created from the + button in the header. If you open the wizard from an API page instead, it adds a final step to put the new entity straight onto that API's schedules.

1. Accommodation — the hotel

On the Accommodations tab, Add accommodations. The wizard opens on three routes:

Search Booking accommodation is the usual one. I have accommodation Booking URL is for when the search is ambiguous and you already have the listing open. Import accommodations from .csv/.xls file is the bulk route.

Search by name. The results carry the hotel's photo and city, and the ones already on your account are greyed out and marked It's yours — which saves you the duplicate:

If nothing matches, use fewer words: the search matches Booking approximately, not your exact string.

Pick one and Continue. Veetal now resolves the listing for real and shows you what it found — stars, guest score, review count, address — plus Profiles Found: which OTAs this hotel actually has a listing on.

In this example Booking, Tripadvisor and Google were found; Expedia and Hotels.com were not. That matters later: an OTA with no profile has nothing to import, and the reputation feed will only return the ones with a green tick. Repeat search profiles runs the detection again if you think it missed one, and View Profile opens the listing it matched so you can check it is the right property.

Add accommodation, and the row appears in the list. The SETUP column is that same profile map, one badge per OTA:

One thing worth knowing: the slug Veetal assigns comes from the Booking URL, not from the display name. "Ohla Barcelona" became ohla. The slug is what every endpoint takes, so copy it from the row rather than guessing it.

2. Location — the destination

The Locations tab, Add locations. The dialog says what it is for: "You will use them to search events in the destination".

Search the destination and you get why this step exists at all:

Four Barcelonas — Spain, Venezuela, Colombia, the Philippines — each with its own coordinates and a Show Map to check. Pick the wrong one and every event you read afterwards is for the wrong city.

⚠️ The name has to be the real destination name. Renaming it to something of your own returns error 731: the pair (destination id, name) is validated against Booking.

Add location and the row lands with its type — Tier 1 here — and its coordinates:

3. Location search — the destination, filtered

The Location searches tab, Add location searches. The finder is richer than the location one: as well as the city it offers districts, the airport, the province and landmarks like the Fira, because a "market" can be any of those.

Step two is the point of this entity — the filters:

Country, currency and language (they change the prices Booking shows), board, stars, property type, and further down distance from centre, minimum score, free cancellation, pet friendly, nights, adults, children, babies and rooms.

These filters are the entity. They define which hotels the search covers — your competitive universe — and therefore how much every run of the feed costs. The example here is 4 and 5 star hotels in Barcelona, one night, two adults. Add location search, and the row shows the filters back as chips:

4. Flight — the route

The Flights tab, Add flights. This is the most self-contained of the four: airports are resolved locally, so it works even when the OTAs don't.

Type a city and you get its airports with their IATA codes — London alone offers seven:

Then trip type, dates, passengers, and two fields that are required and easy to miss: LANGUAGE and COUNTRY. They are the point of sale — the market whose prices you want — not the route. Leave one empty and the field turns red with This field is required and Add flight stays disabled.

A Round trip needs a date range; One way takes a single date.

The same thing over the API

Every one of the four has a matching account endpoint, so you can do all of this from code once you know the shape:

POST /v2/account/accommodation · POST /v2/account/location · POST /v2/account/location-search · POST /v2/account/flight

And GET on the same paths lists what you have, which is how you get the slugs and ids the data endpoints need.

What happens next

Entities on their own don't fetch anything. From here the path forks: a Real Time endpoint will answer about them immediately, one request at a time; a Feed dataset needs an import to have run first, which you set up as a schedule on that API's page. Each row also has activate, deactivate and delete, and the checkboxes give you the same three in bulk — a deactivated entity stops being imported without losing its history.